Thanks The INVITE is received from a VOIP provider, on the kamailio box, and forwarded to the asterisk box. For all my voip provider, it works fine, but just for one, the ACK is not passed onto the asterisk box, but a trace shows that the ACK is sent by kamailio to kamaiio - I have attached below the SIP packets for the original invite and the ACK that gets incorrectly forwarded,
J. 2017/12/26 15:21:47.414524 VOIP-IP:5060 -> KAMAILIOIP:5060 INVITE sip:CALLED-NUM@KAMAILIOIP SIP/2.0 Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKh5r5mp20007mno86oit0.1 P-Asserted-Identity: <sip:[email protected]> To: <sip:CALLED-NUM@KAMAILIOIP:5060> From: <sip:[email protected]>;tag=SDf1f0501- 496399c4-0016-096a-0000-0000 Call-ID: SDf1f0501-70980730711ea436a8ed241985dddc7d-v300g00040 CSeq: 1 INVITE Max-Forwards: 65 Contact: <sip:CALLING-NUM@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@KAMAILIOIP:5060 SIP/2.0 Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKmdfnm110182k1pbvl180.1 To: <sip:KAMAILIOIP:5060>;tag=as3eec8631 From: <sip:[email protected]>;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:[email protected]>;tag=SDf1f0501- 496399c4-0016-096a-0000-0000 Call-ID: SDf1f0501-70980730711ea436a8ed241985dddc7d-v300g00040 CSeq: 1 ACK Max-Forwards: 65 Content-Length: 0 On Tue, Jan 2, 2018 at 9:19 AM, Wilkins, Steve <[email protected]> wrote: > Hello, > > > > Have you done a trace tcpdump/Wireshark? What does the traffic look > like? Are Asterisk and Kamailio on different Servers? > > > > -Steve > > > > *From:* sr-users [mailto:[email protected]] *On Behalf > Of *Jean Cérien > *Sent:* Tuesday, January 2, 2018 8:04 AM > *To:* Daniel-Constantin Mierla <[email protected]> > *Cc:* Kamailio (SER) - Users Mailing List <[email protected]> > *Subject:* Re: [SR-Users] t_relay dying ? > > > > > > 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 <[email protected]> > 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@KAMAILIOIP SIP/2.0 > > Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKh5r5mp20007mno86oit0.1 > > P-Asserted-Identity: <sip:[email protected]> > > To: <sip:CALLED-NUM@KAMAILIOIP:5060> > > From: <sip:[email protected]>;tag=SDf1f0501- > 496399c4-0016-096a-0000-0000 > > Call-ID: SDf1f0501-70980730711ea436a8ed241985dddc7d-v300g00040 > > CSeq: 1 INVITE > > Max-Forwards: 65 > > Contact: <sip:CALLING-NUM@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@KAMAILIOIP:5060 SIP/2.0 > > Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKmdfnm110182k1pbvl180.1 > > To: <sip:KAMAILIOIP:5060>;tag=as3eec8631 > > From: <sip:[email protected]>;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:[email protected]>;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 < > [email protected]> 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 [email protected]} 2(20129) ERROR: <script>: =======* > request ACK before relay > {1 2 ACK [email protected]} 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 < > [email protected]> 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 <[email protected]> > 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 <[email protected]>: > > > > 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:[email protected]>;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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
