Re: [SR-Users] t_relay dying ?

2 Jan 2018

      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:CALLING-NUM@orange-multimedia.fr
To: sip:CALLED-NUM@KAMAILIOIP:5060
From: sip:CALLING-NUM@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@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:CALLING-NUM@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@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 Tue, Jan 2, 2018 at 9:19 AM, Wilkins, Steve swwilkins@mitre.org 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:sr-users-bounces@lists.kamailio.org] *On Behalf
Of *Jean Cérien
*Sent:* Tuesday, January 2, 2018 8:04 AM
*To:* Daniel-Constantin Mierla miconda@gmail.com
*Cc:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org
*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 cerien.jean@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@KAMAILIOIP SIP/2.0
Via: SIP/2.0/UDP VOIP-IP:5060;branch=z9hG4bKh5r5mp20007mno86oit0.1
P-Asserted-Identity: sip:CALLING-NUM@orange-multimedia.fr
To: sip:CALLED-NUM@KAMAILIOIP:5060
From: sip:CALLING-NUM@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@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:CALLING-NUM@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@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@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@127.0.0.1}  2(20129) ERROR: <script>: =======*
request ACK before relay
{1 2 ACK 1473723014@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@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@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@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
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Kamailio (SER) - Users Mailing List
sr-users@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Re: [SR-Users] t_relay dying ?