[SR-Users] t_relay dying ?
Jean Cérien
cerien.jean at gmail.com
Tue Jan 2 14:04:22 CET 2018
Hello
Any suggestion as to why the ACK is not forwarded to the Asterisk box and
stays on the kamailio server ?
REgards
J.
On Tue, Dec 26, 2017 at 11:49 AM, Jean Cérien <cerien.jean at gmail.com> wrote:
>
> Daniel
>
> Many thanks for your help in this holidays season.
>
> The ACK is now going out and executions follows, which is good, however,
> the ack is sent to the Kamailio box itself and not actually forwarded to
> the asterisk (I've attached at the end of this message the initial invite,
> received ACK and "forwarded" ACK).
>
> Both packet go through very classic config, starting with dlg_manage(),
> then if (has_totag()), if (loose_route()), which leads to route(RELAY),
> which does the actual call to t_relay.
>
> This sequence works fine with other providers, I cant see what is wrong !
>
> Regards
> J
>
>
> *Initial invite received from provider*
>
> 2017/12/26 15:21:47.414524 VOIP-IP:5060 -> KAMAILIOIP:5060
> INVITE sip:CALLED-NUM at KAMAILIOIP SIP/2.0
> Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKh5r5mp20007mno86oit0.1
> P-Asserted-Identity: <sip:CALLING-NUM at orange-multimedia.fr>
> To: <sip:CALLED-NUM at KAMAILIOIP:5060>
> From: <sip:CALLING-NUM at orange-multimedia.fr>;tag=SDf1f0501-
> 496399c4-0016-096a-0000-0000
> Call-ID: SDf1f0501-70980730711ea436a8ed241985dddc7d-v300g00040
> CSeq: 1 INVITE
> Max-Forwards: 65
> Contact: <sip:CALLING-NUM at VOIP-IP:5060;transport=udp>
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS
> Supported: uui,timer
> Accept: application/sdp, application/isup, application/xml
> P-Access-Network-Info: GSTN;operator-specific-GI="
> 639720000";network-provided
> Content-Type: application/sdp
> Content-Length: 221
> Session-Expires: 1800; refresher=uac
> Min-SE: 90
>
>
> *ACK Received from provider*
>
> 2017/12/26 15:21:47.473423 VOIP-IP:5060 -> KAMAILIOIP:5060
> ACK sip:CALLED-NUM at KAMAILIOIP:5060 SIP/2.0
> Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKmdfnm110182k1pbvl180.1
> To: <sip:KAMAILIOIP:5060>;tag=as3eec8631
> From: <sip:CALLING-NUM at orange-multimedia.fr>;tag=SDf1f0501-
> 496399c4-0016-096a-0000-0000
> Call-ID: SDf1f0501-70980730711ea436a8ed241985dddc7d-v300g00040
> CSeq: 1 ACK
> Max-Forwards: 66
> Content-Length: 0
> Route: <sip:KAMAILIOIP;lr=on;ftag=SDf1f0501-496399c4-0016-096a-
> 0000-0000;did=eea.aa52>
>
>
> *ACK Forwarded*
>
> 2017/12/26 15:21:47.473898* KAMAILIOIP:5060 -> KAMAILIOIP:5060*
> ACK sip:KAMAILIOIP;lr=on;ftag=SDf1f0501-496399c4-0016-096a-0000-0000;did=eea.aa52
> SIP/2.0
> Via: SIP/2.0/UDP KAMAILIOIP;branch=z9hG4bK52bb.
> 2e7f3f0b7c8c60b92bfa2d945cc9829d.0
> Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKmdfnm110182k1pbvl180.1
> To: <sip:KAMAILIOIP:5060>;tag=as3eec8631
> From: <sip:CALLING-NUM at orange-multimedia.fr>;tag=SDf1f0501-
> 496399c4-0016-096a-0000-0000
> Call-ID: SDf1f0501-70980730711ea436a8ed241985dddc7d-v300g00040
> CSeq: 1 ACK
> Max-Forwards: 65
> Content-Length: 0
>
>
>
>
> On Sat, Dec 23, 2017 at 8:12 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> I just tested and works fine. Try with master branch and default config
>> file.
>>
>> To test I modified a bit the default kamailio.cfg and I have in
>> route[RELAY]:
>>
>> xlog("=======* request $rm before relay\n");
>> if (!t_relay()) {
>> xlog("=======x request $rm not relayed\n");
>> sl_reply_error();
>> }
>> xlog("=======> request $rm relayed\n");
>>
>> I get the ACK routed and in logs I get:
>>
>> {1 2 ACK 1473723014 at 127.0.0.1} 2(20129) ERROR: <script>: =======*
>> request ACK before relay
>> {1 2 ACK 1473723014 at 127.0.0.1} 2(20129) ERROR: <script>: =======>
>> request ACK relayed
>>
>> Cheers,
>> Daniel
>>
>> On 22.12.17 21:00, Jean Cérien wrote:
>>
>>
>> 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/52111974b4571e05
>>> 62e8e731df80f48dbc504915
>>>
>>> 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
>>>
>>>
>>
>> --
>> 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/20180102/cb2f26eb/attachment.html>
More information about the sr-users
mailing list