[SR-Users] t_relay dying ?

[Jean Cérien]

Many thanks for your help.
I've applied the patch, recompiled and I see no difference unfortunately.
The ACK is not forwarded, and execution after t_relay stops.

I've set the debug level to 4 and captured the traces - I believe the
section dealing with the ACK is there:  https://pastebin.com/TG03YQWC

KR
J.

On Fri, Dec 22, 2017 at 11:59 AM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:

> Hello,
>
> can you give a try with latest master branch or by using the patch from
> next link?
>
>   - https://github.com/kamailio/kamailio/commit/
> 52111974b4571e0562e8e731df80f48dbc504915
>
> 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 at 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 at 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 at kamailioIP:5060 SIP/2.0
>>> Via: SIP/2.0/UDP VOIPPROVIDERIP:5060;branch=z9h
>>> G4bKjq16fi00d85uee181ic0.1
>>> To: <sip:kamailioIP:5060>;tag=as7f10ed48
>>> From: <sip:sourcenumber at orange-multimedia.fr>;tag=SD8u3ob01-7dd8ef
>>> de-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
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171222/cc29b9f5/attachment.html>