Call Control not behaving

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Call Control not behaving

Douglas Lane
Hi Guys,

Ok I've shifted my routing logic around a bit to accommodate for my
billing_party avp getting populated by the digest auth details instead
of the FROM headers.

Now my call_control() is invoked after the Proxy auth is successful
during the INVITE, however, when the client runs out of credit, the
following happens:

Apr 19 09:50:02 sbc1 call-control[4358]: Call id
[hidden email] of [hidden email] to
sip:[hidden email] forbidden because credit is too low
Apr 19 09:50:02 sbc1 /opt/opensips/sbin/opensips[19378]: Callcontrol
returned code 18446744073709551615

Ofcourse this just freaks things out, and it appears that the call can
still go through.

Any suggestions that I can look into, as the MaxSessionTime stuff looks
correct, the From header is correctly populated, so I'm not sure why its
not working. However, when the client does have credit, callcontrol
returns 1 as per expected.

Thanks
Doug

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Call Control not behaving

Luci Stanescu
On 04/19/2010 10:11 AM, Douglas Lane wrote:
> Hi Guys,

Hi Douglas,

> Apr 19 09:50:02 sbc1 call-control[4358]: Call id
> [hidden email] of [hidden email] to
> sip:[hidden email] forbidden because credit is too low
> Apr 19 09:50:02 sbc1 /opt/opensips/sbin/opensips[19378]: Callcontrol
> returned code 18446744073709551615

That number is the largest 64bit signed integer. The call_control
function returns -1 in case of no credit, so effectively the two numbers
are equivalent (in binary). How are you using the return code of the
call_control function?

--
Luci Stanescu

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Call Control not behaving

Douglas Lane
Hi Luci,

Hmm I should have checked that. Below is my routing logic for call
control (I loaded it into its own route block, and then my invite route
just calls this route block for processing after the proxy auth succeeds)

         if(!isflagset(19))
         {
                 call_control();
                 xlog("L_INFO", "Callcontrol returned code $retcode\n");

                 switch ($retcode)
                 {
                         case 2:
                                 # Call with no limit
                         case 1:
                                 # Call with a limit under callcontrol
management (either prepaid or postpaid)
                                 break;
                         case -1:
                                 xlog("L_INFO", "Call control: not
enough credit for prepaid call\n");
                                 acc_aaa_request("402");
                                 revert_uri();
                                 prefix("u");
                                 rewritehostport("1.2.3.5");        #
This is my asterisk box that says "I'm sorry you got no money left"
                                 route(12);     #basic route block to
have the call over to t_relay()
                                 exit;
                                 break;
                         case -2:
                                 # Locked by call in progress (prepaid call)
                                 xlog("L_INFO", "Call control: prepaid
call locked by another call in progress\n");
                                 acc_aaa_request("403");
                                 sl_send_reply("403", "Call locked by
another call in progress");
                                 exit;
                                 break;
                         default:
                                 # Internal error (message parsing,
communication, ...)
                                 xlog("L_INFO", "Call control: internal
server error\n");
                                 acc_aaa_request("500");
                                 sl_send_reply("500", "Internal server
error");
                                 exit;
                 }

                 ## mark checking done
                 setflag(19);        # I set flag 19 to make sure I
don't go over this again
         }


On 2010/04/19 4:19 PM, Luci Stanescu wrote:

> On 04/19/2010 10:11 AM, Douglas Lane wrote:
>    
>> Hi Guys,
>>      
> Hi Douglas,
>
>    
>> Apr 19 09:50:02 sbc1 call-control[4358]: Call id
>> [hidden email] of [hidden email] to
>> sip:[hidden email] forbidden because credit is too low
>> Apr 19 09:50:02 sbc1 /opt/opensips/sbin/opensips[19378]: Callcontrol
>> returned code 18446744073709551615
>>      
> That number is the largest 64bit signed integer. The call_control
> function returns -1 in case of no credit, so effectively the two numbers
> are equivalent (in binary). How are you using the return code of the
> call_control function?
>
>    

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Call Control not behaving

Laszlo


2010/4/19 Douglas Lane <[hidden email]>
Hi Luci,

Hmm I should have checked that. Below is my routing logic for call
control (I loaded it into its own route block, and then my invite route
just calls this route block for processing after the proxy auth succeeds)

        if(!isflagset(19))
        {
                call_control();
                xlog("L_INFO", "Callcontrol returned code $retcode\n");



it's the last functions return code, in your case it's xlog's retcode :)
(you called xlog before the switch statement)

-Laszlo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Call Control not behaving

Douglas Lane
Hi Laszlo,

Just to make 100% sure, I'm not suppose to call xlog because then retcode would change to what xlog's return would have been?

If so, guess that was stupid on my behalf!

Thanks
Doug

On 2010/04/19 5:14 PM, Laszlo wrote:


2010/4/19 Douglas Lane <[hidden email]>
Hi Luci,

Hmm I should have checked that. Below is my routing logic for call
control (I loaded it into its own route block, and then my invite route
just calls this route block for processing after the proxy auth succeeds)

        if(!isflagset(19))
        {
                call_control();
                xlog("L_INFO", "Callcontrol returned code $retcode\n");



it's the last functions return code, in your case it's xlog's retcode :)
(you called xlog before the switch statement)

-Laszlo
_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Call Control not behaving

Laszlo


2010/4/19 Douglas Lane <[hidden email]>
Hi Laszlo,

Just to make 100% sure, I'm not suppose to call xlog because then retcode would change to what xlog's return would have been?


:)
                xlog("L_INFO", "Callcontrol returned code $retcode\n");

                switch ($retcode)



when you do this, you test the retcode of xlog, and the "switch" will be done by xlog's retcode :)
just comment out and test it:
#xlog("L_INFO", "Callcontrol returned code $retcode\n");

-Laszlo

 
If so, guess that was stupid on my behalf!

Thanks
Doug



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users