[SR-Users] t_relay dying ?
Евгений Голей
goley_ev_sp at mail.ru
Tue Dec 26 17:54:46 CET 2017
Daniel hello!
This is because the provider must respond to the ACK not with KAMAILIOIP: 5060 SIP / 2.0, and in the domain part, asterisk addresses must be specified.
Send the config.
Evgeniy
>Вторник, 26 декабря 2017, 18:53 +03:00 от Jean Cérien <cerien.jean at gmail.com>:
>
>
>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/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=z9hG4bKjq16fi00d85uee181ic0.1
>>>>>>>To: <sip:kamailioIP:5060> ;tag=as7f10ed48
>>>>>>>From:
>>>>>>> < sip:sourcenumber at 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
>>>>>>>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 List
>>>>>sr-users at 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
>>>
>>
>>--
>>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
>
>_______________________________________________
>Kamailio (SER) - Users Mailing List
>sr-users at lists.kamailio.org
>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
С уважением,
Евгений Голей
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171226/b9e6f0ea/attachment.html>
More information about the sr-users
mailing list