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 │ │
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 KAMAILIOASTERISK 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
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 ASTERISK21: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
Hello,
can you give a try with latest master branch or by using the patch from next link?
- https://github.com/kamailio/kamailio/commit/52111974b4571e0562e8e731df80f48d...
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 mailto: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 <mailto: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 <mailto:sip%3Asourcenumber@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 <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <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
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?
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=z9h G4bKjq16fi00d85uee181ic0.1 To: sip:kamailioIP:5060;tag=as7f10ed48 From: sip:sourcenumber@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 ASTERISK21: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 Listsr-users@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
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 mailto: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 <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 <mailto: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 <mailto: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 <mailto:sip%3Asourcenumber@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 <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>-- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - www.asipto.com <http://www.asipto.com> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com <http://www.kamailioworld.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@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?
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@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=z9h G4bKjq16fi00d85uee181ic0.1 To: sip:kamailioIP:5060;tag=as7f10ed48 From: sip:sourcenumber@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 ASTERISK21: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 Listsr-users@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
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@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@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/52111974b4571e0562e8e731df80f48d... 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
Pay attention to the answer 200 ok from asterisk and the one that kamailio sends to the provider side. The ACK specifies the values taken from the Contact header in the response 200 OK
Вторник, 26 декабря 2017, 19:54 +03:00 от Евгений Голей goley_ev_sp@mail.ru:
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@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@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/52111974b4571e0562e8e731df80f48d... 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
-- С уважением, Евгений Голей
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?
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@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=z9h G4bKjq16fi00d85uee181ic0.1 To: sip:kamailioIP:5060;tag=as7f10ed48 From: sip:sourcenumber@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 ASTERISK21: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 Listsr-users@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
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.commailto: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.frmailto:sip%3ACALLING-NUM@orange-multimedia.fr> To: sip:CALLED-NUM@KAMAILIOIP:5060 From: <sip:CALLING-NUM@orange-multimedia.frmailto:sip%3ACALLING-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.frmailto:sip%3ACALLING-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.frmailto:sip%3ACALLING-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.commailto: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.1mailto:1473723014@127.0.0.1} 2(20129) ERROR: <script>: =======* request ACK before relay {1 2 ACK 1473723014@127.0.0.1mailto: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.commailto: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/52111974b4571e0562e8e731df80f48d...
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.commailto: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.commailto: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.frmailto:sip%3Asourcenumber@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.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.comhttp://www.kamailioworld.com
--
Daniel-Constantin Mierla
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.comhttp://www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.comhttp://www.kamailioworld.com
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?
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 KAMAILIOASTERISK
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
Hi Jean,
as pointed out earlier, the ACK is probably broken. Every packet after the 200 OK should have the contact of the 200 OK in the Request URI. Your example packet carries probably the original request URI, which is most certainly wrong, exept if you use some topology hiding.
This is something you can't fix but the voip provider has to fix. They apparently can't handle proxied SIP connections.
Regards, Sebastian
Hello,
if one side of the call is breaking the contact, then a workaround in kamailio is to use htable to store the contact address per callid+from/to tag. I encountered couple of times such situation and the condition in the config file is like:
- if the r-uri of ACK (BYE, etc...) matches "myself", then check to see if there is a record in an htable corresponding to callid and to-tag, if yes, use it
Contact for caller is set in htable as INVITE is received and for callee when then 200ok is received.
If dialog module is used, then the contact from the dialog structure can be used. With 5.1 or newer, dialog offers a dedicated function for this:
- https://www.kamailio.org/docs/modules/stable/modules/dialog.html#dialog.f.dl...
For older versions, the address has to be taken from $dlg(...) variable, with some conditions to detect if it is the caller or callee side.
Cheers, Daniel
On 03.01.18 16:16, Sebastian Damm wrote:
Hi Jean,
as pointed out earlier, the ACK is probably broken. Every packet after the 200 OK should have the contact of the 200 OK in the Request URI. Your example packet carries probably the original request URI, which is most certainly wrong, exept if you use some topology hiding.
This is something you can't fix but the voip provider has to fix. They apparently can't handle proxied SIP connections.
Regards, Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Thanks for this answer. The voip provider is not really eager to alter its SBC as it considers that the contact field is not mandatory in the ACK. The RFC states (section 8.1.1.8)
The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request
The ACK does not establish the dialog, no new call id / dialog id is being generated.
I guess I need to implement the mechanism you've described, unless you think they mis-interpret the RFC,
Regards J.
On Thu, Jan 4, 2018 at 4:48 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
if one side of the call is breaking the contact, then a workaround in kamailio is to use htable to store the contact address per callid+from/to tag. I encountered couple of times such situation and the condition in the config file is like:
- if the r-uri of ACK (BYE, etc...) matches "myself", then check to see
if there is a record in an htable corresponding to callid and to-tag, if yes, use it
Contact for caller is set in htable as INVITE is received and for callee when then 200ok is received.
If dialog module is used, then the contact from the dialog structure can be used. With 5.1 or newer, dialog offers a dedicated function for this:
html#dialog.f.dlg_set_ruri
For older versions, the address has to be taken from $dlg(...) variable, with some conditions to detect if it is the caller or callee side.
Cheers, Daniel
On 03.01.18 16:16, Sebastian Damm wrote:
Hi Jean,
as pointed out earlier, the ACK is probably broken. Every packet after the 200 OK should have the contact of the 200 OK in the Request URI. Your example packet carries probably the original request URI, which is most certainly wrong, exept if you use some topology hiding.
This is something you can't fix but the voip provider has to fix. They apparently can't handle proxied SIP connections.
Regards, Sebastian
Kamailio (SER) - Users Mailing Listsr-users@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
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi,
On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien cerien.jean@gmail.com wrote:
Thanks for this answer. The voip provider is not really eager to alter its SBC as it considers that the contact field is not mandatory in the ACK. The RFC states (section 8.1.1.8)
The problem is not that the ACK doesn't carry a Contact header. The problem is that the ACK is constructed incorrectly. This is what the RfC says to UAC behavior (section 12.1.2):
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. *The remote target MUST be set to the URI from the Contact header field of the response.*
This is what the carrier's SBC gets wrong. It doesn't address your Asterisk but instead addresses your Kamailio, although the Contact of your 200 OK (hopefully) contains the Asterisk IP.
Please verify that your 200 OK going to the carrier actually does carry a Contact header with the Asterisk IP, but if it does, section 12.1.2 of the SIP RfC could help when arguing with the carrier.
Regards Sebastian
Many, many thanks !
I've posted the full dialog unredacted here: https://pastebin.com/EE9iwgZf
The OK from Kamailio back to VOIP provider has Record-Route: sip:KAMAILIOIP;lr=on;ftag=SD2rbta01-8dd0e72b-0016-0379- 0000-0000;did=e0c.e0a1 Contact: sip:NUMBER@ASTERISKIP:5060
So my understanding is that the ACK should be ACK sip:NUMBER@ASTERISKIP:5060 SIP/2.0 .... and not ACK sip:NUMBER@KAMAILIOIP:5060 SIP/2.0
Am I understanding correctly ?
Rgds J
On Mon, Jan 8, 2018 at 11:28 AM, Sebastian Damm damm@sipgate.de wrote:
Hi,
On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien cerien.jean@gmail.com wrote:
Thanks for this answer. The voip provider is not really eager to alter its SBC as it considers that the contact field is not mandatory in the ACK. The RFC states (section 8.1.1.8)
The problem is not that the ACK doesn't carry a Contact header. The problem is that the ACK is constructed incorrectly. This is what the RfC says to UAC behavior (section 12.1.2):
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. *The remote target MUST be set to the URI from the Contact header field of the response.*
This is what the carrier's SBC gets wrong. It doesn't address your Asterisk but instead addresses your Kamailio, although the Contact of your 200 OK (hopefully) contains the Asterisk IP.
Please verify that your 200 OK going to the carrier actually does carry a Contact header with the Asterisk IP, but if it does, section 12.1.2 of the SIP RfC could help when arguing with the carrier.
Regards Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi
While I'm trying to get the provider fix the SBC, I am implementing the workaround.
Almost done here, storing and retrieving the correct address is fine, but when I set my $ru to the corrected value (asterisk IP), the t_relay still sends the packet to the kamailio IP -
$ru="sip:number@asteriskip:5060"; if (!t_relay()) { ....
Why would the t_relay forward to the kamailio IP and not the asterisk ?
Rgds J
On Mon, Jan 8, 2018 at 11:49 AM, Jean Cérien cerien.jean@gmail.com wrote:
Many, many thanks !
I've posted the full dialog unredacted here: https://pastebin.com/EE9iwgZf
The OK from Kamailio back to VOIP provider has Record-Route: sip:KAMAILIOIP;lr=on;ftag=SD2rbta01-8dd0e72b-0016-0379-0000 -0000;did=e0c.e0a1 Contact: sip:NUMBER@ASTERISKIP:5060
So my understanding is that the ACK should be ACK sip:NUMBER@ASTERISKIP:5060 SIP/2.0 .... and not ACK sip:NUMBER@KAMAILIOIP:5060 SIP/2.0
Am I understanding correctly ?
Rgds J
On Mon, Jan 8, 2018 at 11:28 AM, Sebastian Damm damm@sipgate.de wrote:
Hi,
On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien cerien.jean@gmail.com wrote:
Thanks for this answer. The voip provider is not really eager to alter its SBC as it considers that the contact field is not mandatory in the ACK. The RFC states (section 8.1.1.8)
The problem is not that the ACK doesn't carry a Contact header. The problem is that the ACK is constructed incorrectly. This is what the RfC says to UAC behavior (section 12.1.2):
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. *The remote target MUST be set to the URI from the Contact header field of the response.*
This is what the carrier's SBC gets wrong. It doesn't address your Asterisk but instead addresses your Kamailio, although the Contact of your 200 OK (hopefully) contains the Asterisk IP.
Please verify that your 200 OK going to the carrier actually does carry a Contact header with the Asterisk IP, but if it does, section 12.1.2 of the SIP RfC could help when arguing with the carrier.
Regards Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Just a hint here, try setting $du and then t_relay...
On Mon, Jan 8, 2018 at 11:55 Jean Cérien cerien.jean@gmail.com wrote:
Hi
While I'm trying to get the provider fix the SBC, I am implementing the workaround.
Almost done here, storing and retrieving the correct address is fine, but when I set my $ru to the corrected value (asterisk IP), the t_relay still sends the packet to the kamailio IP -
$ru="sip:number@asteriskip:5060"; if (!t_relay()) { ....
Why would the t_relay forward to the kamailio IP and not the asterisk ?
Rgds J
On Mon, Jan 8, 2018 at 11:49 AM, Jean Cérien cerien.jean@gmail.com wrote:
Many, many thanks !
I've posted the full dialog unredacted here: https://pastebin.com/EE9iwgZf
The OK from Kamailio back to VOIP provider has Record-Route: sip:KAMAILIOIP;lr=on;ftag=SD2rbta01-8dd0e72b-0016-0379-0000-0000;did=e0c.e0a1 Contact: sip:NUMBER@ASTERISKIP:5060
So my understanding is that the ACK should be ACK sip:NUMBER@ASTERISKIP:5060 SIP/2.0 .... and not ACK sip:NUMBER@KAMAILIOIP:5060 SIP/2.0
Am I understanding correctly ?
Rgds J
On Mon, Jan 8, 2018 at 11:28 AM, Sebastian Damm damm@sipgate.de wrote:
Hi,
On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien cerien.jean@gmail.com wrote:
Thanks for this answer. The voip provider is not really eager to alter its SBC as it considers that the contact field is not mandatory in the ACK. The RFC states (section 8.1.1.8)
The problem is not that the ACK doesn't carry a Contact header. The problem is that the ACK is constructed incorrectly. This is what the RfC says to UAC behavior (section 12.1.2):
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. *The remote target MUST be set to the URI from the Contact header field of the response.*
This is what the carrier's SBC gets wrong. It doesn't address your Asterisk but instead addresses your Kamailio, although the Contact of your 200 OK (hopefully) contains the Asterisk IP.
Please verify that your 200 OK going to the carrier actually does carry a Contact header with the Asterisk IP, but if it does, section 12.1.2 of the SIP RfC could help when arguing with the carrier.
Regards Sebastian
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
Many thanks, I've managed to handle a call properly.
I really want to thank Daniel, and all that have helped on this subject.
Regards J.
On Mon, Jan 8, 2018 at 11:42 PM, Joel Serrano joel@gogii.net wrote:
Just a hint here, try setting $du and then t_relay...
On Mon, Jan 8, 2018 at 11:55 Jean Cérien cerien.jean@gmail.com wrote:
Hi
While I'm trying to get the provider fix the SBC, I am implementing the workaround.
Almost done here, storing and retrieving the correct address is fine, but when I set my $ru to the corrected value (asterisk IP), the t_relay still sends the packet to the kamailio IP -
$ru="sip:number@asteriskip:5060"; if (!t_relay()) { ....
Why would the t_relay forward to the kamailio IP and not the asterisk ?
Rgds J
On Mon, Jan 8, 2018 at 11:49 AM, Jean Cérien cerien.jean@gmail.com wrote:
Many, many thanks !
I've posted the full dialog unredacted here: https://pastebin.com/ EE9iwgZf
The OK from Kamailio back to VOIP provider has Record-Route: sip:KAMAILIOIP;lr=on;ftag=SD2rbta01-8dd0e72b-0016-0379- 0000-0000;did=e0c.e0a1 Contact: sip:NUMBER@ASTERISKIP:5060
So my understanding is that the ACK should be ACK sip:NUMBER@ASTERISKIP:5060 SIP/2.0 .... and not ACK sip:NUMBER@KAMAILIOIP:5060 SIP/2.0
Am I understanding correctly ?
Rgds J
On Mon, Jan 8, 2018 at 11:28 AM, Sebastian Damm damm@sipgate.de wrote:
Hi,
On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien cerien.jean@gmail.com wrote:
Thanks for this answer. The voip provider is not really eager to alter its SBC as it considers that the contact field is not mandatory in the ACK. The RFC states (section 8.1.1.8)
The problem is not that the ACK doesn't carry a Contact header. The problem is that the ACK is constructed incorrectly. This is what the RfC says to UAC behavior (section 12.1.2):
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. *The remote target MUST be set to the URI from the Contact header field of the response.*
This is what the carrier's SBC gets wrong. It doesn't address your Asterisk but instead addresses your Kamailio, although the Contact of your 200 OK (hopefully) contains the Asterisk IP.
Please verify that your 200 OK going to the carrier actually does carry a Contact header with the Asterisk IP, but if it does, section 12.1.2 of the SIP RfC could help when arguing with the carrier.
Regards Sebastian
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
Hello. I want to implement the following scheme:
Kami takes inbound call, replces SPD for correct NAT trversal and forward that call to FS. Kami should NOT be in RTP stream. Is it possible? Any advices?
Thanks.
Yes, it is very possible to do that. If you google kamailio / freeswitch / asterisk, there are plenty of tutorials out there.
// Samuel
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Yu Boot yu@yu-boot.ru Sent: Monday, December 25, 2017 10:16:52 AM To: sr-users@lists.kamailio.org Subject: [SR-Users] Kami as NAT traversal + FS as media
Hello. I want to implement the following scheme:
Kami takes inbound call, replces SPD for correct NAT trversal and forward that call to FS. Kami should NOT be in RTP stream. Is it possible? Any advices?
Thanks.
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kama...
Hello,
On 25.12.17 10:16, Yu Boot wrote:
Hello. I want to implement the following scheme:
Kami takes inbound call, replces SPD for correct NAT trversal and forward that call to FS. Kami should NOT be in RTP stream. Is it possible? Any advices?
Kamailio should not touch the SDP if it is not going to do the RTP relaying with rtpengine or rtpproxy. Just leave it untouch, freeswitch will handle what is needed in this regard.
What you have to do is to fix the signaling for nat traversal, which may mean to use path module for handling registrations as well as doing set_contact_alias() as well as handle_ruri_alias(), so you can route requests within dialog.
Cheers, Daniel
Thanks for an answer? but what I want to do (already done :)) is totally opposite to your solution.
The main thing I wanted, so I don't need to open 5060/UDP on FreeSwitch for (entire world), BUT at the same time АЫ should work with RTP traffic directly, no matter is it NATed UAC or not.
This kind of "NAT traversal" (call it RTP NAT traversal :)) and UAC registrar are on Kami side. FS is pure softswitch here.
What I did to perform this is replace rtpproxy_manage("co");
with
fix_nated_sdp("10");
Now it works exactly as I wanted. Thanks for advice.
04.01.2018 12:42, Daniel-Constantin Mierla пишет:
Hello,
On 25.12.17 10:16, Yu Boot wrote:
Hello. I want to implement the following scheme:
Kami takes inbound call, replces SPD for correct NAT trversal and forward that call to FS. Kami should NOT be in RTP stream. Is it possible? Any advices?
Kamailio should not touch the SDP if it is not going to do the RTP relaying with rtpengine or rtpproxy. Just leave it untouch, freeswitch will handle what is needed in this regard.
What you have to do is to fix the signaling for nat traversal, which may mean to use path module for handling registrations as well as doing set_contact_alias() as well as handle_ruri_alias(), so you can route requests within dialog.
Cheers, Daniel
Hello,
On 05.01.18 12:33, Yu Boot wrote:
Thanks for an answer? but what I want to do (already done :)) is totally opposite to your solution.
The main thing I wanted, so I don't need to open 5060/UDP on FreeSwitch for (entire world), BUT at the same time АЫ should work with RTP traffic directly, no matter is it NATed UAC or not.
This kind of "NAT traversal" (call it RTP NAT traversal :)) and UAC registrar are on Kami side. FS is pure softswitch here.
What I did to perform this is replace rtpproxy_manage("co");
with
fix_nated_sdp("10");
Now it works exactly as I wanted. Thanks for advice.
this is not fixing anything from RTP point of view, or better said, it is not something that is working alone with a symmetric nat. You rewrite the SDP IP with source IP, but it should just work the same without rewriting it. For a symmetric nat the media port advertised in SDP is not going to match the allocated port for the rtp flow in the public side of the nat router -- if it does, can be just a luck, which is not going to work forever, especially if there are many sip clients behind same nat router.
Anyhow, what I meant is to fix the SIP headers (not the SDP), so you do SIP routing properly for requests within dialog. The port 5060/udp for FreeSwitch should be open only for traffic from/to kamailio and doesn't have anything to do with the SDP and RTP, nor eliminated if you do nat fix for the headers...
Cheers, Daniel
04.01.2018 12:42, Daniel-Constantin Mierla пишет:
Hello,
On 25.12.17 10:16, Yu Boot wrote:
Hello. I want to implement the following scheme:
Kami takes inbound call, replces SPD for correct NAT trversal and forward that call to FS. Kami should NOT be in RTP stream. Is it possible? Any advices?
Kamailio should not touch the SDP if it is not going to do the RTP relaying with rtpengine or rtpproxy. Just leave it untouch, freeswitch will handle what is needed in this regard.
What you have to do is to fix the signaling for nat traversal, which may mean to use path module for handling registrations as well as doing set_contact_alias() as well as handle_ruri_alias(), so you can route requests within dialog.
Cheers, Daniel
Hi You said that only thing changed is the Provider chanded their end. Have you compared the previous signaling to the current ? Previous I mean before provider change their switch. Could there be some difference and that causes this error.
Tomi
On 21 Dec 2017, at 23.01, Jean Cérien cerien.jean@gmail.com wrote:
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
-
Daniel-Constantin Mierla -
Jean Cérien -
Joel Serrano -
Samuel F. -
Sebastian Damm -
Sergey Safarov -
Tomi Hakkarainen -
Wilkins, Steve -
Yu Boot -
Евгений Голей