Re: [SR-Users] t_relay dying ?

Hello, can you give a try with latest master branch or by using the patch from next link?   - https://github.com/kamailio/kamailio/commit/52111974b4571e0562e8e731df80f48… Apparently the t_realy() stopped script execution (by returning 0) when e2e ACK forwarding was successful. The patch should change that to return true. If all works fine while testing, then I will backport. Cheers, Daniel On 22.12.17 14:05, Jean Cérien wrote: > >Hello >I've tried mhomed = 1 with no luck - not so > sure what you mean by default route, I've added > listen = udp:myadsress:5060 >I also have auto_aliases=no and > alias=myaddress > >However, what bugs me is that execution > seems to stop INSIDE t_relay and the info > message after the t_relay is not displayed.  > >I hate to say this, but could this be a bug > ? > >Rgds >J. > > >On Fri, Dec 22, 2017 at > 1:52 AM, Sergey Safarov < s.safarov(a)gmail.com > wrote: >>Check that your installation >> have one NIC with only one default route on >> host. >>If not check that "mhomed=1" is >> enabled. >> >>Sergey >>пт, 22 дек. 2017 г. в 0:02, >> Jean Cérien < cerien.jean(a)gmail.com >: >>> >>>Hello >>>I am using kamailio 5.0.2, on a >>> debian 9 system. >>> >>>Everything was running fine, until >>> one of our voip provider changed his >>> switch. Our kamailio is relaying >>> between several voip providers and >>> several asterisk (only the >>> signalisation, no rtp). >>> >>>When we get an invite from this new >>> switch, we select an asterisk and >>> relay it correctly to this box. >>> However, the OK is relayed back. But >>> when the voip providers sends an ACK >>> for this OK, the t_relay function does >>> not return at all, it just dies with >>> no action and no error. >>> >>>Here is the snippet from >>> route(relay) >>> >>>        >>> xlog("L_INFO","route(relay)  @@ $rm >>> - Source: $si:$sp, fu:$fu, tu:$tu\n" >>> ); >>>        >>> $var(restrelay)=t_relay(); >>>        >>> xlog("L_INFO","route(relay)  @@ $rm >>> - t_relay result: $var(restrelay)" >>> ); >>>        if (!$var(restrelay)) { >>> >>>When processing the initial invite, >>> I do get both INFO messages. When the >>> ACK is processed, I only get one INFO >>> message, and no ACK is relayed - so it >>> seems execution dies in the t_relay >>> >>>What could be wrong ??? >>> >>>J. >>> >>>Details of the ACK: >>> >>>ACK sip:dialednumber@kamailioIP :5060 >>> SIP/2.0 >>>Via: >>> SIP/2.0/UDP >>> VOIPPROVIDERIP:5060;branch=z9hG4bKjq16fi00d85uee181ic0.1 >>>To: <sip:kamailioIP:5060> ;tag=as7f10ed48 >>>From: >>> < sip:sourcenumber@orange-multimedia.fr >;tag=SD8u3ob01-7dd8efde-0002-00d5-0000-0000 >>>Call-ID: >>> SD8u3ob01-688d41f5e2164ceeafe76f40b82b3f97-v300g00030 >>>CSeq: >>> 1 ACK >>>Max-Forwards: >>> 66 >>>Content-Length: >>> 0 >>>Route: >>> < sip:kamailioIP;lr=on;ftag= SD8u3ob01-7dd8efde-0002-00d5-0000-0000;did=a0b.49d> >>> >>> >>> >>>(should you have enough width; the >>> diagram will look ok) >>> >>>  >>>                  VOIP PROVIDER    >>>            KAMAILIO                >>>        ASTERISK >>>  >>> 21:38:54.685149   │ >>> ──────────────────────────> │  >>>                            │    >>>▒  >>>       +0.000451    │  100 trying -- >>> your call is │                    >>>          │    >>>▒ >>> 21:38:54.685600   │ >>> <────────────────────────── │  >>>                            │    >>>▒  >>>       +0.000084    │                >>>              │        INVITE >>> (SDP)         │    >>>▒ >>> 21:38:54.685684   │                >>>              │ >>> ──────────────────────────> │  >>>   >>>▒  >>>       +0.000831    │                >>>              │         100 Trying  >>>         │    >>>▒ >>> 21:38:54.686515   │                >>>              │ >>> <────────────────────────── │  >>>   >>>▒  >>>       +0.000471    │                >>>              │        200 OK >>> (SDP)         │    >>>▒ >>> 21:38:54.686986   │                >>>              │ >>> <────────────────────────── │  >>>   >>>▒  >>>       +0.000394    │        200 OK >>> (SDP)         │                    >>>          │    >>>▒ >>> 21:38:54.687380   │ >>> <────────────────────────── │  >>>                            │    >>>▒  >>>       +0.038694    │            >>>  ACK             │                >>>              │    >>>▒ >>> 21:38:54.726074   │ >>> ──────────────────────────> │  >>>                            │    >>>▒  >>>       +0.060155    │                >>>              │        200 OK >>> (SDP)         │    >>>▒ >>> 21:38:54.786229   │                >>>              │ >>> <<<──────────────────────── >>> │    >>>▒  >>>       +0.000138    │        200 OK >>> (SDP)         │                    >>>          │    >>>▒ >>> 21:38:54.786367   │ >>> <<<──────────────────────── >>> │                             │    >>>▒  >>>       +0.005721    │            >>>  ACK             │                >>>              │  >>> >>> >>>_______________________________________________ >>>Kamailio (SER) - Users Mailing List &gt;&gt;&gt;sr-users(a)lists.kamailio.org >>>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >>_______________________________________________ >>Kamailio (SER) - Users Mailing List &gt;&gt;sr-users(a)lists.kamailio.org >>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > > >_______________________________________________ >Kamailio (SER) - Users Mailing List &gt;sr-users(a)lists.kamailio.org >https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com