Hi all
Follow scenario
Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
I get Invites from [c5] with Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw] And sending to [carr] in international format
Request, to, from, contact, ... => 417794445566 Everything ok
Then I get a 100, 183 and even 200 from [carr] Ack is coming from [c5] to [lbl] and [gw] - but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see DEBUG: RFC3261 transaction matching failed DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) { xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n"); if ( t_check_trans() ) { xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n"); # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n"); # ACK without matching transaction ... ignore and discard route(NATMANAGE); #t_relay(); #exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping OIi
Hi,
Does the ACK has the correct Router headers and R-URI? Maybe you can share the 200 OK and the ACK headers..
I had a similar issue 3 weeks ago.
Cheers, Francisco.
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 15:55 To: sr-users@lists.sip-router.org Subject: [SR-Users] ACK / BYE transaction problem
Hi all
Follow scenario
Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
I get Invites from [c5] with Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw] And sending to [carr] in international format
Request, to, from, contact, ... => 417794445566 Everything ok
Then I get a 100, 183 and even 200 from [carr] Ack is coming from [c5] to [lbl] and [gw] - but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see DEBUG: RFC3261 transaction matching failed DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) { xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n"); if ( t_check_trans() ) { xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n"); # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n"); # ACK without matching transaction ... ignore and discard route(NATMANAGE); #t_relay(); #exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping OIi
I removed the changes for the to header - so it is not touched all the time
200 ok from [carr]
SIP/2.0 200 OK From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70;tag=snl_0015024070 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 INVITE Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0 Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131 Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422 Record-Route: sip:185.49.222.43;lr=on Contact: sip:794567735@81.7.235.236:5060;transport=udp Content-Type: application/sdp Content-Length: 197 Accept-Language: en;q=0.0 Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, UPDATE Supported: timer Session-Expires: 1800;refresher=uas Date: Wed, 29 Jun 2016 13:44:20 GMT
v=0 o=- 277262053 1 IN IP4 81.7.235.228 s=- c=IN IP4 81.7.235.228 t=0 0 m=audio 24212 RTP/AVP 8 101 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=ptime:20
ACK from [lbl] to [gw]
ACK sip:185.49.222.44;did=4b7.9422;lr=on SIP/2.0
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70;tag=snl_0015024070
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 ACK
Max-Forwards: 28
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a6f12b66454fbb7b536aa22cef3d568c.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.7bc483a166362b13ba3cc40ca60308ea.0
Via: SIP/2.0/UDP 212.25.7.69:5060;branch=z9hG4bKsc1NXPTEST-ae749ab817378131A
Content-Length: 0
X-gateway: <null>
X-SI: <null>
X-gateway: <null>
X-SI: <null>
Initial Inivte to [gw] from [lbl]
INVITE sip:0794567735@185.49.222.43:5060 SIP/2.0
Record-Route: sip:185.49.222.43;lr=on
From: sip:0275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 29
User-Agent: AareSwitch/6.2.8553
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Contact: sip:0275279225@212.25.7.69:5060
P-Asserted-Identity: sip:0275279225@212.25.7.69
Content-Type: application/sdp
Content-Length: 401
Invite sent to [carr] from [gw]
INVITE sip:41794567735@81.7.235.236 SIP/2.0
Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422
Record-Route: sip:185.49.222.43;lr=on
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 28
User-Agent: AareSwitch/6.2.8553
Contact: sip:41279225@212.25.7.69
Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
P-Asserted-Identity: sip:41275279225@212.25.7.69;user=phone
Content-Type: application/sdp
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero Gesendet: Mittwoch, 29. Juni 2016 16:00 An: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Betreff: Re: [SR-Users] ACK / BYE transaction problem
Hi,
Does the ACK has the correct Router headers and R-URI? Maybe you can share the 200 OK and the ACK headers..
I had a similar issue 3 weeks ago.
Cheers, Francisco.
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 15:55 To: sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Subject: [SR-Users] ACK / BYE transaction problem
Hi all
Follow scenario
Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
I get Invites from [c5] with Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw] And sending to [carr] in international format
Request, to, from, contact, ... => 417794445566 Everything ok
Then I get a 100, 183 and even 200 from [carr] Ack is coming from [c5] to [lbl] and [gw] - but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see DEBUG: RFC3261 transaction matching failed DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) { xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n"); if ( t_check_trans() ) { xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n"); # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n"); # ACK without matching transaction ... ignore and discard route(NATMANAGE); #t_relay(); #exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping OIi
Your ACK is missing the right IP in the RURI (should be the one in the contact header in the 200 OK) and the Route headers for every Record-Route in the 200 OK, if I understand well your scenario...
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 16:04 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: Re: [SR-Users] ACK / BYE transaction problem
I removed the changes for the to header - so it is not touched all the time
200 ok from [carr]
SIP/2.0 200 OK From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70;tag=snl_0015024070 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 INVITE Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0 Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131 Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422 Record-Route: sip:185.49.222.43;lr=on Contact: sip:794567735@81.7.235.236:5060;transport=udp Content-Type: application/sdp Content-Length: 197 Accept-Language: en;q=0.0 Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, UPDATE Supported: timer Session-Expires: 1800;refresher=uas Date: Wed, 29 Jun 2016 13:44:20 GMT
v=0 o=- 277262053 1 IN IP4 81.7.235.228 s=- c=IN IP4 81.7.235.228 t=0 0 m=audio 24212 RTP/AVP 8 101 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=ptime:20
ACK from [lbl] to [gw]
ACK sip:185.49.222.44;did=4b7.9422;lr=on SIP/2.0
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70;tag=snl_0015024070
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 ACK
Max-Forwards: 28
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a6f12b66454fbb7b536aa22cef3d568c.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.7bc483a166362b13ba3cc40ca60308ea.0
Via: SIP/2.0/UDP 212.25.7.69:5060;branch=z9hG4bKsc1NXPTEST-ae749ab817378131A
Content-Length: 0
X-gateway: <null>
X-SI: <null>
X-gateway: <null>
X-SI: <null>
Initial Inivte to [gw] from [lbl]
INVITE sip:0794567735@185.49.222.43:5060 SIP/2.0
Record-Route: sip:185.49.222.43;lr=on
From: sip:0275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 29
User-Agent: AareSwitch/6.2.8553
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Contact: sip:0275279225@212.25.7.69:5060
P-Asserted-Identity: sip:0275279225@212.25.7.69
Content-Type: application/sdp
Content-Length: 401
Invite sent to [carr] from [gw]
INVITE sip:41794567735@81.7.235.236 SIP/2.0
Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422
Record-Route: sip:185.49.222.43;lr=on
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 28
User-Agent: AareSwitch/6.2.8553
Contact: sip:41279225@212.25.7.69
Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
P-Asserted-Identity: sip:41275279225@212.25.7.69;user=phone
Content-Type: application/sdp
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero Gesendet: Mittwoch, 29. Juni 2016 16:00 An: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Betreff: Re: [SR-Users] ACK / BYE transaction problem
Hi,
Does the ACK has the correct Router headers and R-URI? Maybe you can share the 200 OK and the ACK headers..
I had a similar issue 3 weeks ago.
Cheers, Francisco.
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 15:55 To: sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Subject: [SR-Users] ACK / BYE transaction problem
Hi all
Follow scenario
Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
I get Invites from [c5] with Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw] And sending to [carr] in international format
Request, to, from, contact, ... => 417794445566 Everything ok
Then I get a 100, 183 and even 200 from [carr] Ack is coming from [c5] to [lbl] and [gw] - but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see DEBUG: RFC3261 transaction matching failed DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) { xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n"); if ( t_check_trans() ) { xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n"); # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n"); # ACK without matching transaction ... ignore and discard route(NATMANAGE); #t_relay(); #exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping OIi
Yes the ip for the [carr] is missing.
But I thought, the [gw ] should create the ack based on the transaction and send it to the [carr]
My situation Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
So who is doing a mistake? The lbl, the gw or even the c5 system?
If helpful, I could provide a trace with all the stations in it.
Kr, Oli
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero Gesendet: Mittwoch, 29. Juni 2016 16:17 An: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Betreff: Re: [SR-Users] ACK / BYE transaction problem
Your ACK is missing the right IP in the RURI (should be the one in the contact header in the 200 OK) and the Route headers for every Record-Route in the 200 OK, if I understand well your scenario...
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 16:04 To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Subject: Re: [SR-Users] ACK / BYE transaction problem
I removed the changes for the to header - so it is not touched all the time
200 ok from [carr]
SIP/2.0 200 OK From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70;tag=snl_0015024070 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 INVITE Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0 Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131 Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422 Record-Route: sip:185.49.222.43;lr=on Contact: sip:794567735@81.7.235.236:5060;transport=udp Content-Type: application/sdp Content-Length: 197 Accept-Language: en;q=0.0 Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, UPDATE Supported: timer Session-Expires: 1800;refresher=uas Date: Wed, 29 Jun 2016 13:44:20 GMT
v=0 o=- 277262053 1 IN IP4 81.7.235.228 s=- c=IN IP4 81.7.235.228 t=0 0 m=audio 24212 RTP/AVP 8 101 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=ptime:20
ACK from [lbl] to [gw]
ACK sip:185.49.222.44;did=4b7.9422;lr=on SIP/2.0
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70;tag=snl_0015024070
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 ACK
Max-Forwards: 28
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a6f12b66454fbb7b536aa22cef3d568c.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.7bc483a166362b13ba3cc40ca60308ea.0
Via: SIP/2.0/UDP 212.25.7.69:5060;branch=z9hG4bKsc1NXPTEST-ae749ab817378131A
Content-Length: 0
X-gateway: <null>
X-SI: <null>
X-gateway: <null>
X-SI: <null>
Initial Inivte to [gw] from [lbl]
INVITE sip:0794567735@185.49.222.43:5060 SIP/2.0
Record-Route: sip:185.49.222.43;lr=on
From: sip:0275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 29
User-Agent: AareSwitch/6.2.8553
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Contact: sip:0275279225@212.25.7.69:5060
P-Asserted-Identity: sip:0275279225@212.25.7.69
Content-Type: application/sdp
Content-Length: 401
Invite sent to [carr] from [gw]
INVITE sip:41794567735@81.7.235.236 SIP/2.0
Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422
Record-Route: sip:185.49.222.43;lr=on
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 28
User-Agent: AareSwitch/6.2.8553
Contact: sip:41279225@212.25.7.69
Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
P-Asserted-Identity: sip:41275279225@212.25.7.69;user=phone
Content-Type: application/sdp
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero Gesendet: Mittwoch, 29. Juni 2016 16:00 An: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Betreff: Re: [SR-Users] ACK / BYE transaction problem
Hi,
Does the ACK has the correct Router headers and R-URI? Maybe you can share the 200 OK and the ACK headers..
I had a similar issue 3 weeks ago.
Cheers, Francisco.
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 15:55 To: sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Subject: [SR-Users] ACK / BYE transaction problem
Hi all
Follow scenario
Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
I get Invites from [c5] with Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw] And sending to [carr] in international format
Request, to, from, contact, ... => 417794445566 Everything ok
Then I get a 100, 183 and even 200 from [carr] Ack is coming from [c5] to [lbl] and [gw] - but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see DEBUG: RFC3261 transaction matching failed DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) { xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n"); if ( t_check_trans() ) { xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n"); # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n"); # ACK without matching transaction ... ignore and discard route(NATMANAGE); #t_relay(); #exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping OIi
Hello,
can you get the traffic on load balancer (or the first hop in your network that received the invite)? There you can see if the fault is in your network or not.
In kamailio.cfg, be sure you don't use fix_nated_contact() function unless you are the first hop receiving the sip message (request or reply). As a matter of fact, fix_nated_contact() should not be used anymore, use set_contact_alias() instead and handle requests within dialog with handle_ruri_alias() -- see default kamailio.cfg for latest kamailio versions.
Cheers, Daniel
On 29/06/16 17:20, Oliver Roth wrote:
Yes the ip for the [carr] is missing.
But I thought, the [gw ] should create the ack based on the transaction and send it to the [carr]
My situation
Class5 system [c5] àLoadbalancer kamailio (dispatcher module) [lbl] -àgateway kamailio [gw] àcarrier [carr]
So who is doing a mistake? The lbl, the gw or even the c5 system?
If helpful, I could provide a trace with all the stations in it.
Kr,
Oli
*Von:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *Im Auftrag von *Francisco Valentin Vinagrero *Gesendet:* Mittwoch, 29. Juni 2016 16:17 *An:* Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org *Betreff:* Re: [SR-Users] ACK / BYE transaction problem
Your ACK is missing the right IP in the RURI (should be the one in the contact header in the 200 OK) and the Route headers for every Record-Route in the 200 OK, if I understand well your scenario…
*From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Oliver Roth *Sent:* 29 June 2016 16:04 *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org> *Subject:* Re: [SR-Users] ACK / BYE transaction problem
I removed the changes for the to header – so it is not touched all the time
200 ok from [carr]
SIP/2.0 200 OK
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70;tag=snl_0015024070
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422
Record-Route: sip:185.49.222.43;lr=on
Contact: sip:794567735@81.7.235.236:5060;transport=udp
Content-Type: application/sdp
Content-Length: 197
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, UPDATE
Supported: timer
Session-Expires: 1800;refresher=uas
Date: Wed, 29 Jun 2016 13:44:20 GMT
v=0
o=- 277262053 1 IN IP4 81.7.235.228
s=-
c=IN IP4 81.7.235.228
t=0 0
m=audio 24212 RTP/AVP 8 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=ptime:20
ACK from [lbl] to [gw]
ACK sip:185.49.222.44;did=4b7.9422;lr=on SIP/2.0 From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70;tag=snl_0015024070 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 ACK Max-Forwards: 28 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a6f12b66454fbb7b536aa22cef3d568c.0 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.7bc483a166362b13ba3cc40ca60308ea.0 Via: SIP/2.0/UDP 212.25.7.69:5060;branch=z9hG4bKsc1NXPTEST-ae749ab817378131A Content-Length: 0 X-gateway: <null> X-SI: <null> X-gateway: <null> X-SI: <null>
Initial Inivte to [gw] from [lbl]
INVITE sip:0794567735@185.49.222.43:5060 SIP/2.0 Record-Route: sip:185.49.222.43;lr=on From: sip:0275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, BYE, OPTIONS Max-Forwards: 29 User-Agent: AareSwitch/6.2.8553 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0 Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131 Contact: sip:0275279225@212.25.7.69:5060 P-Asserted-Identity: sip:0275279225@212.25.7.69 Content-Type: application/sdp Content-Length: 401
Invite sent to [carr] from [gw]
INVITE sip:41794567735@81.7.235.236 SIP/2.0 Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422 Record-Route: sip:185.49.222.43;lr=on From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, BYE, OPTIONS Max-Forwards: 28 User-Agent: AareSwitch/6.2.8553 Contact: sip:41279225@212.25.7.69 Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0 Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131 P-Asserted-Identity: sip:41275279225@212.25.7.69;user=phone Content-Type: application/sdp
*Von:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *Im Auftrag von *Francisco Valentin Vinagrero *Gesendet:* Mittwoch, 29. Juni 2016 16:00 *An:* Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org> *Betreff:* Re: [SR-Users] ACK / BYE transaction problem
Hi,
Does the ACK has the correct Router headers and R-URI? Maybe you can share the 200 OK and the ACK headers..
I had a similar issue 3 weeks ago.
Cheers, Francisco.
*From:*sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On Behalf Of *Oliver Roth *Sent:* 29 June 2016 15:55 *To:* sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org *Subject:* [SR-Users] ACK / BYE transaction problem
Hi all
Follow scenario
Class5 system [c5] àLoadbalancer kamailio (dispatcher module) [lbl] -àgateway kamailio [gw] àcarrier [carr]
I get Invites from [c5] with
Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw]
And sending to [carr] in international format
Request, to, from, contact, … => 417794445566
Everything ok
Then I get a 100, 183 and even 200 from [carr]
Ack is coming from [c5] to [lbl] and [gw] – but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see
DEBUG: RFC3261 transaction matching failed
DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) {
xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n");
if (t_check_trans() ) {
xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n");
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
t_relay();
exit;
} else {xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n");
# ACK without matching transaction ... ignore and discard
route(NATMANAGE);
#t_relay();
#exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping
OIi
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel
Yes I get all the traffic in the lbl (first hop) and on the gw (routing gw). Even the call is processed and I get rtp on both sides.
But: ACK is not routed to the carrier behind the gw. Therefore the call gets cut from carrierside – because of missing ACK after 200 OK
I could provide a complete trace from the whole scenario.
About your inputs: Where should they be done? On the LBL (dispatcher, first hop) or on the gateway (gw)?
Regards, Oli
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Daniel-Constantin Mierla Gesendet: Freitag, 1. Juli 2016 09:55 An: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Betreff: Re: [SR-Users] ACK / BYE transaction problem
Hello,
can you get the traffic on load balancer (or the first hop in your network that received the invite)? There you can see if the fault is in your network or not.
In kamailio.cfg, be sure you don't use fix_nated_contact() function unless you are the first hop receiving the sip message (request or reply). As a matter of fact, fix_nated_contact() should not be used anymore, use set_contact_alias() instead and handle requests within dialog with handle_ruri_alias() -- see default kamailio.cfg for latest kamailio versions.
Cheers, Daniel
On 29/06/16 17:20, Oliver Roth wrote: Yes the ip for the [carr] is missing.
But I thought, the [gw ] should create the ack based on the transaction and send it to the [carr]
My situation Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
So who is doing a mistake? The lbl, the gw or even the c5 system?
If helpful, I could provide a trace with all the stations in it.
Kr, Oli
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero Gesendet: Mittwoch, 29. Juni 2016 16:17 An: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Betreff: Re: [SR-Users] ACK / BYE transaction problem
Your ACK is missing the right IP in the RURI (should be the one in the contact header in the 200 OK) and the Route headers for every Record-Route in the 200 OK, if I understand well your scenario…
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 16:04 To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Subject: Re: [SR-Users] ACK / BYE transaction problem
I removed the changes for the to header – so it is not touched all the time
200 ok from [carr]
SIP/2.0 200 OK From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61 To: sip:0794567735@212.25.7.70;tag=snl_0015024070 Call-ID: 5773d0ab9b30-5bau50gxp4en CSeq: 1 INVITE Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0 Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0 Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131 Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422 Record-Route: sip:185.49.222.43;lr=on Contact: sip:794567735@81.7.235.236:5060;transport=udp Content-Type: application/sdp Content-Length: 197 Accept-Language: en;q=0.0 Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, UPDATE Supported: timer Session-Expires: 1800;refresher=uas Date: Wed, 29 Jun 2016 13:44:20 GMT
v=0 o=- 277262053 1 IN IP4 81.7.235.228 s=- c=IN IP4 81.7.235.228 t=0 0 m=audio 24212 RTP/AVP 8 101 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=ptime:20
ACK from [lbl] to [gw]
ACK sip:185.49.222.44;did=4b7.9422;lr=on SIP/2.0
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70;tag=snl_0015024070
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 ACK
Max-Forwards: 28
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a6f12b66454fbb7b536aa22cef3d568c.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.7bc483a166362b13ba3cc40ca60308ea.0
Via: SIP/2.0/UDP 212.25.7.69:5060;branch=z9hG4bKsc1NXPTEST-ae749ab817378131A
Content-Length: 0
X-gateway: <null>
X-SI: <null>
X-gateway: <null>
X-SI: <null>
Initial Inivte to [gw] from [lbl]
INVITE sip:0794567735@185.49.222.43:5060 SIP/2.0
Record-Route: sip:185.49.222.43;lr=on
From: sip:0275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 29
User-Agent: AareSwitch/6.2.8553
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
Contact: sip:0275279225@212.25.7.69:5060
P-Asserted-Identity: sip:0275279225@212.25.7.69
Content-Type: application/sdp
Content-Length: 401
Invite sent to [carr] from [gw]
INVITE sip:41794567735@81.7.235.236 SIP/2.0
Record-Route: sip:185.49.222.44;lr=on;did=4b7.9422
Record-Route: sip:185.49.222.43;lr=on
From: sip:41275279225@212.25.7.69;tag=sc1NXPTEST-4c9b51343502af61
To: sip:0794567735@212.25.7.70
Call-ID: 5773d0ab9b30-5bau50gxp4en
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Max-Forwards: 28
User-Agent: AareSwitch/6.2.8553
Contact: sip:41279225@212.25.7.69
Via: SIP/2.0/UDP 185.49.222.44;branch=z9hG4bKbe7c.0f5ca21e3a66f41694ca709ac28c1192.0
Via: SIP/2.0/UDP 185.49.222.43;branch=z9hG4bKbe7c.a5e4cba8b1d9a4a56d1120d012a06850.0
Via: SIP/2.0/UDP 212.25.7.69:5060;uac=sc1;branch=z9hG4bKsc1NXPTEST-ae749ab817378131
P-Asserted-Identity: sip:41275279225@212.25.7.69;user=phone
Content-Type: application/sdp
Von: sr-users [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Francisco Valentin Vinagrero Gesendet: Mittwoch, 29. Juni 2016 16:00 An: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org> Betreff: Re: [SR-Users] ACK / BYE transaction problem
Hi,
Does the ACK has the correct Router headers and R-URI? Maybe you can share the 200 OK and the ACK headers..
I had a similar issue 3 weeks ago.
Cheers, Francisco.
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Oliver Roth Sent: 29 June 2016 15:55 To: sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org Subject: [SR-Users] ACK / BYE transaction problem
Hi all
Follow scenario
Class5 system [c5] --> Loadbalancer kamailio (dispatcher module) [lbl] ---> gateway kamailio [gw] --> carrier [carr]
I get Invites from [c5] with Request ,To, from, contact, pid in national format 0794445566
[lbl] dispatches this to [gw]
For the [carr] I need international format.
So doing these transactions in [gw] And sending to [carr] in international format
Request, to, from, contact, … => 417794445566 Everything ok
Then I get a 100, 183 and even 200 from [carr] Ack is coming from [c5] to [lbl] and [gw] – but then it stocks
The ACK is not sent to the [carr]
I kamailio log I see DEBUG: RFC3261 transaction matching failed DEBUG: t_lookup_request: no transaction found
So for me, the ACK cannot be assigned to a transaction and gets discarded by
if ( is_method("ACK") ) { xlog(,"L_INFO", "WITHINDLG ACK - not loose route\n"); if ( t_check_trans() ) { xlog(,"L_INFO", "WITHINDLG ACK - t_check_trans() \n"); # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { xlog(,"L_INFO", "WITHINDLG ACK - not t_check_trans() DISCARD!!\n"); # ACK without matching transaction ... ignore and discard route(NATMANAGE); #t_relay(); #exit;
Any idea?
Problem with modifying the sip tags? Or problem with the dialog?
Thanks for helping OIi
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-
Daniel-Constantin Mierla -
Francisco Valentin Vinagrero -
Oliver Roth