[OpenSIPS-Users] Strange entries in ACC

Jim DeVito jim at devito.cc
Wed Apr 26 12:15:24 EDT 2017


Correct. Assuming all the destinations that the load balancer module send
to gives me a negative reply I turn around and send the 600 to my upstream.

On Wed, Apr 26, 2017 at 12:13 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> So, your call is actually proxied out (to a switch), but the 600 reply is
> generated by you in failure route (upon a 408 timeout ?)
>
> Bogdan-Andrei Iancu
>   OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
>
> OpenSIPS Summit May 2017 Amsterdam
>   http://www.opensips.org/events/Summit-2017Amsterdam.html
>
> On 04/26/2017 07:10 PM, Jim DeVito wrote:
>
> Every time. Just routing the number to a non existent destination in my
> class 5 switch so that it ends up hitting the failure route.
>
> On Wed, Apr 26, 2017 at 12:08 PM, Bogdan-Andrei Iancu <
> <bogdan at opensips.org>bogdan at opensips.org> wrote:
>
>> And I suppose you can reproduce such funky records, right ?
>>
>> Bogdan-Andrei Iancu
>>   OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>>
>> OpenSIPS Summit May 2017 Amsterdam
>>   http://www.opensips.org/events/Summit-2017Amsterdam.html
>>
>> On 04/26/2017 06:50 PM, Jim DeVito wrote:
>>
>> Correct.
>> do_accounting("db", "cdr|failed|missed", "acc");
>> And I meant the username part of the R-URI so it has an 11 digit phone
>> number in it.
>> On Wed, Apr 26, 2017 at 11:48 AM, Bogdan-Andrei Iancu <
>> bogdan at opensips.org> wrote:
>>>
>>> OK, thanks. I suppose you have the "failed" flag set in do_accounting()
>>> ? And before ending the INVITE processing, do you change the RURI (you
>>> mentioned it originally has a username) ? Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>   OpenSIPS Founder and Developer
>>>   http://www.opensips-solutions.com
>>>
>>> OpenSIPS Summit May 2017 Amsterdam
>>>   http://www.opensips.org/events/Summit-2017Amsterdam.html
>>>
>>> On 04/26/2017 06:33 PM, Jim DeVito wrote:
>>>
>>> Yes. And correct the script is rejecting the call at this point and
>>> returning the 600 to my upstream.
>>> On Wed, Apr 26, 2017 at 11:28 AM, Bogdan-Andrei Iancu <
>>> bogdan at opensips.org> wrote:
>>>>
>>>> Again, does the strange text correspond to the to_tn extra value ? And
>>>> the call is rejected by you from script ? it not ever proxied further,
>>>> right ? Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>   OpenSIPS Founder and Developer
>>>>   http://www.opensips-solutions.com
>>>>
>>>> OpenSIPS Summit May 2017 Amsterdam
>>>>   http://www.opensips.org/events/Summit-2017Amsterdam.html
>>>>
>>>> On 04/26/2017 06:25 PM, Jim DeVito wrote:
>>>>
>>>> Hi Bogdan,
>>>> Sorry forgot the mention I am using 2.2.3 the latest stable from the
>>>> repo. I put a log line just after send_reply("600","Busy Everywhere"); and
>>>> $rU looks good there. Is there another place I should put a log line to see
>>>> the value of $rU?
>>>> Thanks!!
>>>> On Wed, Apr 26, 2017 at 11:16 AM, Bogdan-Andrei Iancu <
>>>> bogdan at opensips.org> wrote:
>>>>>
>>>>> Hi Jim, What OpenSIPS version do you use ? Is the x00 string
>>>>> corresponding to the to_tn extra field ? If yes, is there any chance to
>>>>> have the $rU null (no username in RURI) ? Regards,
>>>>>
>>>>> Bogdan-Andrei Iancu
>>>>>   OpenSIPS Founder and Developer
>>>>>   http://www.opensips-solutions.com
>>>>>
>>>>> OpenSIPS Summit May 2017 Amsterdam
>>>>>   http://www.opensips.org/events/Summit-2017Amsterdam.html
>>>>>
>>>>> On 04/26/2017 05:43 PM, Jim DeVito wrote:
>>>>>
>>>>> Hi All,
>>>>> So I am seeing the below record in the ACC output that is causing me
>>>>> problems else where. Notice the \x00\x00\x00\x00\x00\x00\x00\x
>>>>> 00\x00\x00 part.
>>>>> INVITE|gK0c48d4aa||1464632400_16750753 at REDACTED|600|Busy
>>>>> Everywhere|1493217263|\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
>>>>> 00|+1REDACTED|sip-proxy03|from-PSTN|REDACTED||8877||
>>>>> In every other ACC entry the value is to be the user part of the
>>>>> request URI as described here...
>>>>> modparam("acc", "db_extra", "to_tn=$rU; (etc....)
>>>>> Except when the call goes through the below failure route.
>>>>> failure_route[orig_load_balance_fail] {
>>>>>         if (t_was_cancelled()) {
>>>>>                 exit();
>>>>>         }
>>>>>         if (t_check_status("[56][0-9][0-9]") ||
>>>>> t_local_replied("all")) {
>>>>>                 if (lb_next()) {
>>>>>                         t_on_failure("orig_load_balance_fail");
>>>>>                         t_relay();
>>>>>                         exit();
>>>>>                 } else {
>>>>>                         send_reply("600","Busy Everywhere");
>>>>>                         exit();
>>>>>                 }
>>>>>         }
>>>>> }
>>>>>
>>>>> Thoughts?
>>>>> Thanks!!
>>>>> Jim D.
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>> --
>>>> -------------
>>>> Jim DeVito
>>>> Mobile 216.507.9497 <%28216%29%20507-9497>
>>>>
>>>> --
>>> -------------
>>> Jim DeVito
>>> Mobile 216.507.9497 <%28216%29%20507-9497>
>>>
>>> --
>> -------------
>> Jim DeVito
>> Mobile 216.507.9497 <%28216%29%20507-9497>
>>
>> --
> -------------
> Jim DeVito
> Mobile 216.507.9497 <(216)%20507-9497>
>
>


-- 
-------------
Jim DeVito
Mobile 216.507.9497
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170426/5858f4bb/attachment.html>


More information about the Users mailing list