[SR-Users] Relaying failure codes back to initial server

Alexandru Covalschi 568691 at gmail.com
Tue Dec 15 13:55:01 CET 2015


Yes, sometimes there are more than one INVITE (custom platform specific
behavior), in case of 1 INVITE per-dialogue it works nice. Can you suggest
something to cover such cases?

2015-12-15 14:12 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:

> Maybe there is a parallel forking and one branch gets timed out (in this
> case 408 is selected against 486). How many INVITE requests do you see
> being sent out? Or you can eventually make the sip trace available for
> viewing on this mailing list or some web site/pastebin out there.
>
> Cheers,
> Daniel
>
>
> On 15/12/15 12:54, Alexandru Covalschi wrote:
>
> I use sngrep to track view the flow and I'm pretty sure it's accurate
> enough to tell me that.
> Here's relay route:
> route[RELAY] {
>
>         # enable additional event routes for forwarded requests
>         # - serial forking, RTP relaying handling, a.s.o.
>         if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
>                 if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
>         }
>         if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
>                 if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
>         }
>         if (is_method("INVITE")) {
>                 if(!t_is_set("failure_route"))
> t_on_failure("MANAGE_FAILURE");
>         }
>         if (!t_relay()) {
>                 sl_reply_error();
>         }
>         exit;
> }
>
> and here's reply routes
>
> # Manage outgoing branches
> branch_route[MANAGE_BRANCH] {
>         xdbg("new branch [$T_branch_idx] to $ru\n");
>         route(NATMANAGE);
> }
>
> # Manage incoming replies
> onreply_route[MANAGE_REPLY] {
>         xdbg("incoming reply\n");
>         if(status=~"[12][0-9][0-9]")
>                 route(NATMANAGE);
> }
>
> # Manage failure routing cases
> failure_route[MANAGE_FAILURE] {
>
> if (t_check_status("486")) {
>     exit;
> }
>         route(NATMANAGE);
>
>         if (t_is_canceled()) {
>                 exit;
>         }
>
> }
>
>
> However when endpoint replies with 486 BUSY I can't see that on FS,
> Kamailio just sends 408 REQ TERM after some amount of time
>
> 2015-12-15 13:34 GMT+02:00 Alex Balashov <abalashov at evaristesys.com>:
>
>> From what you describe, the reply should be going back to the sender. Are
>> you absolutely sure that it's not? If so, are there any other actions you
>> could be taking somewhere to drop it, such as in an onreply_route?
>>
>> ACKs to negative final replies are hop-by-hop, so the ACK you're seeing
>> directly from the proxy to the UAS is normal.
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>> 303 Perimeter Center North, Suite 300
>> Atlanta, GA 30346
>> United States
>>
>> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
>> Web: http://www.evaristesys.com/,  <http://www.csrpswitch.com/>
>> http://www.csrpswitch.com/
>>
>> Sent from my BlackBerry.
>> *From: *Alexandru Covalschi
>> *Sent: *Tuesday, December 15, 2015 05:03
>> *To: *Kamailio (SER) - Users Mailing List
>> *Reply To: *Kamailio (SER) - Users Mailing List
>> *Subject: *[SR-Users] Relaying failure codes back to initial server
>>
>> Hello everyone!
>> I need to relay 486/408/... other failure codes back to initial INVITE
>> server. Here
>> <http://lists.sip-router.org/pipermail/sr-users/2010-November/066382.html>
>> http://lists.sip-router.org/pipermail/sr-users/2010-November/066382.html
>> is recommended just to exit failure_route, but that didn't work for me. I
>> need that to let Freeswitch know which cause has ended the call. Now
>> Kamailio just sends ACK to endpoint on receiving 486 BUSY. Would you kindly
>> tell me how to achieve that?
>> Thanks in advance
>> --
>> Alexandru Covalschi
>> ABRISS-Solutions
>> VoIP engineer and system administrator
>> phone: +37367398493
>> web: http://abs-telecom.com/
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Alexandru Covalschi
> ABRISS-Solutions
> VoIP engineer and system administrator
> phone: +37367398493
> web: http://abs-telecom.com/
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Book: SIP Routing With Kamailio - http://www.asipto.comhttp://miconda.eu
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
Alexandru Covalschi
ABRISS-Solutions
VoIP engineer and system administrator
phone: +37367398493
web: http://abs-telecom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20151215/0df8662b/attachment.html>


More information about the sr-users mailing list