Looking into the topos module of 4.4.2 I see something unexpected, ACK and BYE are routed directly to the Contact in the 200 OK on an INVITE where the 200 OK has a Record-Route.
Without the topos module the message flow is as expected: 109.235.32.57<->185.61.68.106<->109.235.32.55 With topos the ACK and BYE take a different route: 109.235.32.57<->185.61.68.106<->109.235.32.55 <->109.235.32.48
109.235.32.5x are proxies. 185.61.68.106 is the registrar
To my understanding, in the callflow below the ACK should be send via the proxy that inserted Record-Route: sip:109.235.32.55;lr in the 200 OK. Am I wrong to conclude this or the topos module ignoring the routing?
Also note the To/From are passed untouched in the ACK/BYE and the BYE to the called endpoint hasn't had its Via headers stripped.
Call scenario: tryba/+31407110xxx calls 0880100XXX. Both are registered to 185.61.68.106 via proxies (resp. 109.235.32.57 and 109.235.32.55)
From 109.235.32.57 -> 185.61.68.106:
INVITE sip:0880100XXX@sip.itco.nl SIP/2.0 Record-Route: sip:109.235.32.57;r2=on;lr Record-Route: sip:109.235.32.57;transport=tcp;r2=on;lr Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.e15a4ffb2c3a7f882117b80c85f75223.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bKb5004b60de287221 Route: sip:109.235.32.57;transport=tcp;lr From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl Contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.34.226~5067~2
From 185.61.68.106 -> 109.235.32.55:
INVITE sip:+31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK7dd7.d4cdfe8014e0d5d806b4dc4a7422c8e0.1 Route: sip:loadbalancer@109.235.32.55;lr;received=sip:109.235.32.48:5060 From: sip:+31407110XXX@sip.itco.nl;tag=576aff337d33fbe5 To: sip:+31880100XXX@sip.itco.nl Contact: sip:btpsh-57b6cc75-f42d-1@185.61.68.106
From 109.235.32.55 -> 185.61.68.106:
SIP/2.0 200 OK Via: SIP/2.0/UDP 185.61.68.106;rport=5060;branch=z9hG4bK7dd7.d4cdfe8014e0d5d806b4dc4a7422c8e0.1 Record-Route: sip:109.235.32.55;lr From: sip:+31407110XXX@sip.itco.nl;tag=576aff337d33fbe5 To: sip:+31880100XXX@sip.itco.nl;tag=as61fc6a47 Contact: sip:%2b31880100XXX@109.235.32.48
From 185.61.68.106 -> 109.235.32.57
SIP/2.0 200 OK From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.e15a4ffb2c3a7f882117b80c85f75223.0;i=60c,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bKb5004b60de287221 Contact: sip:atpsh-57b6cc75-f42d-2@185.61.68.106 Record-Route: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr
From 109.235.32.57 -> 185.61.68.106:
ACK sip:atpsh-57b6cc75-f42d-2@185.61.68.106 SIP/2.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.a49ec0c055166a1935ff84cfca4d1a5c.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK24aff2df2ee7b43f From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47 Contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.34.226~5067~2
From 185.61.68.106 -> 109.235.32.48
ACK sip:%2b31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK7dd7.ac1b9a45042f9c26277afb9ec32bebe0.0 From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47 Contact: sip:btpsh-57b6cc75-f42d-1@185.61.68.106
From 109.235.32.57 -> 185.61.68.106
BYE sip:atpsh-57b6cc75-f42d-2@185.61.68.106 SIP/2.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK4dd7.24da86af0a970ee399c9504933d8d751.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK0d8db1380c5011b6 From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47
From 185.61.68.106 -> 109.235.32.48
BYE sip:%2b31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK4dd7.4916bf7bcaa3b0346e43c3785a9be782.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK4dd7.24da86af0a970ee399c9504933d8d751.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK0d8db1380c5011b6 From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47
Hello,
can you try with git master branch? There were some fixes there which were not ported yet (they will get into next 4.4.x release, which will be sometime in the next 2 weeks).
Cheers, Daniel
On 19/08/16 12:11, Daniel Tryba wrote:
Looking into the topos module of 4.4.2 I see something unexpected, ACK and BYE are routed directly to the Contact in the 200 OK on an INVITE where the 200 OK has a Record-Route.
Without the topos module the message flow is as expected: 109.235.32.57<->185.61.68.106<->109.235.32.55 With topos the ACK and BYE take a different route: 109.235.32.57<->185.61.68.106<->109.235.32.55 <->109.235.32.48
109.235.32.5x are proxies. 185.61.68.106 is the registrar
To my understanding, in the callflow below the ACK should be send via the proxy that inserted Record-Route: sip:109.235.32.55;lr in the 200 OK. Am I wrong to conclude this or the topos module ignoring the routing?
Also note the To/From are passed untouched in the ACK/BYE and the BYE to the called endpoint hasn't had its Via headers stripped.
Call scenario: tryba/+31407110xxx calls 0880100XXX. Both are registered to 185.61.68.106 via proxies (resp. 109.235.32.57 and 109.235.32.55)
From 109.235.32.57 -> 185.61.68.106: INVITE sip:0880100XXX@sip.itco.nl SIP/2.0 Record-Route: sip:109.235.32.57;r2=on;lr Record-Route: sip:109.235.32.57;transport=tcp;r2=on;lr Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.e15a4ffb2c3a7f882117b80c85f75223.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bKb5004b60de287221 Route: sip:109.235.32.57;transport=tcp;lr From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl Contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.34.226~5067~2
From 185.61.68.106 -> 109.235.32.55: INVITE sip:+31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK7dd7.d4cdfe8014e0d5d806b4dc4a7422c8e0.1 Route: sip:loadbalancer@109.235.32.55;lr;received=sip:109.235.32.48:5060 From: sip:+31407110XXX@sip.itco.nl;tag=576aff337d33fbe5 To: sip:+31880100XXX@sip.itco.nl Contact: sip:btpsh-57b6cc75-f42d-1@185.61.68.106
From 109.235.32.55 -> 185.61.68.106: SIP/2.0 200 OK Via: SIP/2.0/UDP 185.61.68.106;rport=5060;branch=z9hG4bK7dd7.d4cdfe8014e0d5d806b4dc4a7422c8e0.1 Record-Route: sip:109.235.32.55;lr From: sip:+31407110XXX@sip.itco.nl;tag=576aff337d33fbe5 To: sip:+31880100XXX@sip.itco.nl;tag=as61fc6a47 Contact: sip:%2b31880100XXX@109.235.32.48
From 185.61.68.106 -> 109.235.32.57 SIP/2.0 200 OK From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.e15a4ffb2c3a7f882117b80c85f75223.0;i=60c,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bKb5004b60de287221 Contact: sip:atpsh-57b6cc75-f42d-2@185.61.68.106 Record-Route: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr
From 109.235.32.57 -> 185.61.68.106: ACK sip:atpsh-57b6cc75-f42d-2@185.61.68.106 SIP/2.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.a49ec0c055166a1935ff84cfca4d1a5c.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK24aff2df2ee7b43f From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47 Contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.34.226~5067~2
From 185.61.68.106 -> 109.235.32.48 ACK sip:%2b31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK7dd7.ac1b9a45042f9c26277afb9ec32bebe0.0 From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47 Contact: sip:btpsh-57b6cc75-f42d-1@185.61.68.106
From 109.235.32.57 -> 185.61.68.106 BYE sip:atpsh-57b6cc75-f42d-2@185.61.68.106 SIP/2.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK4dd7.24da86af0a970ee399c9504933d8d751.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK0d8db1380c5011b6 From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47
From 185.61.68.106 -> 109.235.32.48 BYE sip:%2b31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK4dd7.4916bf7bcaa3b0346e43c3785a9be782.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK4dd7.24da86af0a970ee399c9504933d8d751.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK0d8db1380c5011b6 From: sip:tryba@sip.itco.nl;tag=576aff337d33fbe5 To: sip:0880100XXX@sip.itco.nl;tag=as61fc6a47
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
On Mon, Aug 22, 2016 at 09:19:52AM +0200, Daniel-Constantin Mierla wrote:
can you try with git master branch? There were some fixes there which were not ported yet (they will get into next 4.4.x release, which will be sometime in the next 2 weeks).
Just tried it, makes no difference. The patch to the topos module is only a few lines (ignoring docu and include stuff).
Taking a look at the database entries during the call for the same scenario, the record-routes from callee are never set. a_rr contains the RR for the proxy of the caller (109.235.32.57), s_rr contains the registrar 185.61.68.106. b_rr is always empty (109.235.32.5[56] are nowhere to be found).
select * from topos_d \G
*************************** 1. row *************************** id: 2 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b9-2 b_uuid: btpsh-57bac150-95b9-1 a_contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.XX.YYY~5067~2 b_contact: as_contact: sip:atpsh-57bac150-95b9-2@185.61.68.106 bs_contact: sip:btpsh-57bac150-95b9-1@185.61.68.106 a_tag: a90e54420669b32b b_tag: a_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr b_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA-- iflags: 0 a_uri: b_uri: r_uri: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 2. row *************************** id: 6 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: btpsh-57bac150-95b3-3 a_contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.XX.YYY~5067~2 b_contact: sip:%2b31880100XXX@109.235.32.48 as_contact: sip:atpsh-57bac150-95b3-4@185.61.68.106 bs_contact: sip:btpsh-57bac150-95b3-3@185.61.68.106 a_tag: a90e54420669b32b b_tag: as1057e8ba a_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr b_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--;vst=AAAAABsLCQgJAAEHAQRxQCkDRxlaChtNAUJubA-- iflags: 1 a_uri: b_uri: r_uri: a_srcaddr: b_srcaddr: a_socket: b_socket:
select * from topos_t\G
*************************** 1. row *************************** id: 2 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b9-2 b_uuid: btpsh-57bac150-95b9-1 direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.74e4ea1d55b7270623bfa1e09a1c087b.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK40d03cc06a039e02 x_vbranch: z9hG4bK1ed2.aaaca95f0dd4b05f301cf64ec2084687.0 x_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr y_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA-- x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 2. row *************************** id: 6 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: btpsh-57bac150-95b3-3 direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.74e4ea1d55b7270623bfa1e09a1c087b.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK40d03cc06a039e02 x_vbranch: z9hG4bK1ed2.aaaca95f0dd4b05f301cf64ec2084687.1 x_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr y_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--;vst=AAAAABsLCQgJAAEHAQRxQCkDRxlaChtNAUJubA-- x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 5. row *************************** id: 18 rectime: 2016-08-22 11:13:23 s_method: ACK s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.2fa09a9197ea2b0b83dfb58916f805ad.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK6abe56e55367de33 x_vbranch: z9hG4bK1ed2.5ed2954acf483e107d2b6edbdc4b5e3c.0 x_rr: y_rr: s_rr: x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket:
On 22/08/16 11:42, Daniel Tryba wrote:
On Mon, Aug 22, 2016 at 09:19:52AM +0200, Daniel-Constantin Mierla wrote:
can you try with git master branch? There were some fixes there which were not ported yet (they will get into next 4.4.x release, which will be sometime in the next 2 weeks).
Just tried it, makes no difference. The patch to the topos module is only a few lines (ignoring docu and include stuff).
Taking a look at the database entries during the call for the same scenario, the record-routes from callee are never set.
OK -- I will try to get to it in the next few days, it is a bug if it is not in the database.
Cheers, Daniel
a_rr contains the RR for the proxy of the caller (109.235.32.57), s_rr contains the registrar 185.61.68.106. b_rr is always empty (109.235.32.5[56] are nowhere to be found).
select * from topos_d \G
*************************** 1. row *************************** id: 2 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b9-2 b_uuid: btpsh-57bac150-95b9-1 a_contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.XX.YYY~5067~2 b_contact: as_contact: sip:atpsh-57bac150-95b9-2@185.61.68.106 bs_contact: sip:btpsh-57bac150-95b9-1@185.61.68.106 a_tag: a90e54420669b32b b_tag: a_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr b_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA-- iflags: 0 a_uri: b_uri: r_uri: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 2. row *************************** id: 6 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: btpsh-57bac150-95b3-3 a_contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.XX.YYY~5067~2 b_contact: sip:%2b31880100XXX@109.235.32.48 as_contact: sip:atpsh-57bac150-95b3-4@185.61.68.106 bs_contact: sip:btpsh-57bac150-95b3-3@185.61.68.106 a_tag: a90e54420669b32b b_tag: as1057e8ba a_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr b_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--;vst=AAAAABsLCQgJAAEHAQRxQCkDRxlaChtNAUJubA-- iflags: 1 a_uri: b_uri: r_uri: a_srcaddr: b_srcaddr: a_socket: b_socket:
select * from topos_t\G
*************************** 1. row *************************** id: 2 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b9-2 b_uuid: btpsh-57bac150-95b9-1 direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.74e4ea1d55b7270623bfa1e09a1c087b.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK40d03cc06a039e02 x_vbranch: z9hG4bK1ed2.aaaca95f0dd4b05f301cf64ec2084687.0 x_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr y_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA-- x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 2. row *************************** id: 6 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: btpsh-57bac150-95b3-3 direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.74e4ea1d55b7270623bfa1e09a1c087b.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK40d03cc06a039e02 x_vbranch: z9hG4bK1ed2.aaaca95f0dd4b05f301cf64ec2084687.1 x_rr: sip:109.235.32.57;r2=on;lr,sip:109.235.32.57;transport=tcp;r2=on;lr y_rr: s_rr: sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--;vst=AAAAABsLCQgJAAEHAQRxQCkDRxlaChtNAUJubA-- x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 5. row *************************** id: 18 rectime: 2016-08-22 11:13:23 s_method: ACK s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad@10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.2fa09a9197ea2b0b83dfb58916f805ad.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK6abe56e55367de33 x_vbranch: z9hG4bK1ed2.5ed2954acf483e107d2b6edbdc4b5e3c.0 x_rr: y_rr: s_rr: x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket:
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
On 24/08/16 08:09, Daniel-Constantin Mierla wrote:
On 22/08/16 11:42, Daniel Tryba wrote:
On Mon, Aug 22, 2016 at 09:19:52AM +0200, Daniel-Constantin Mierla wrote:
can you try with git master branch? There were some fixes there which were not ported yet (they will get into next 4.4.x release, which will be sometime in the next 2 weeks).
Just tried it, makes no difference. The patch to the topos module is only a few lines (ignoring docu and include stuff).
Taking a look at the database entries during the call for the same scenario, the record-routes from callee are never set.
OK -- I will try to get to it in the next few days, it is a bug if it is not in the database.
Finally some time to look at the source code for it ... can you run with higher debug level for topos and grab the message printed by the module that is like "... compacted headers - a_rr: ... b_rr: ..."?
Cheers, Daniel
On Fri, Aug 26, 2016 at 01:55:13PM +0200, Daniel-Constantin Mierla wrote:
Finally some time to look at the source code for it ... can you run with higher debug level for topos and grab the message printed by the module that is like "... compacted headers - a_rr: ... b_rr: ..."?
Attached a pcap of the call and the topos debug lines from syslog during that call , my guess is you need more than only the compated header line.
I hope you can make any sense of (I can't :)
I pushed a new commit, can you give it another try?
Cheers, Daniel
On 29/08/16 12:11, Daniel Tryba wrote:
On Fri, Aug 26, 2016 at 01:55:13PM +0200, Daniel-Constantin Mierla wrote:
Finally some time to look at the source code for it ... can you run with higher debug level for topos and grab the message printed by the module that is like "... compacted headers - a_rr: ... b_rr: ..."?
Attached a pcap of the call and the topos debug lines from syslog during that call , my guess is you need more than only the compated header line.
I hope you can make any sense of (I can't :)
On Tue, Aug 30, 2016 at 03:15:14PM +0200, Daniel-Constantin Mierla wrote:
I pushed a new commit, can you give it another try?
A quick test confirms that the previous scenario is now handled correctly. ACK and BYE are now routed correctly (not end to end based on contact).
I'll try to test all call scenarios tomorrow.
Thanks for the quick fix.
I'll try to test all call scenarios tomorrow.
Thanks for the quick fix.
Well, I found a new bug. If the callee wants session-timers and sets the uac as refresher, the ACK on the 200 OK of the session-timer re-INVITE isn't handled correctly. The ACK will be send directly to the contact of the callee. If the callee designated the uas as refresher, all goes well.
Attached a pcap showing this problem (the initial INVITE to the callee is missing for some reason (fragmented?)) and the topos related debugging from the timeperiod.
BTW syslog is getting spammed with ERROR: topos [tps_storage.c:874]: tps_storage_load_dialog(): no dlg uuid provided these are related to locally generated OPTIONS by the dispatcher and nathelper modules.
On Wed, Aug 31, 2016 at 03:56:10PM +0200, Daniel Tryba wrote:
Attached a pcap showing this problem (the initial INVITE to the callee is missing for some reason (fragmented?)) and the topos related debugging from the timeperiod.
How hard is it to not forget to attach them when writing this :)
On 31/08/16 15:57, Daniel Tryba wrote:
On Wed, Aug 31, 2016 at 03:56:10PM +0200, Daniel Tryba wrote:
Attached a pcap showing this problem (the initial INVITE to the callee is missing for some reason (fragmented?)) and the topos related debugging from the timeperiod.
How hard is it to not forget to attach them when writing this :)
I pushed a new commit, aiming to avoid overwriting record route set with session updates. Let me know if it makes the difference.
Cheers, Daniel
On Thu, Sep 01, 2016 at 03:07:46PM +0200, Daniel-Constantin Mierla wrote:
I pushed a new commit, aiming to avoid overwriting record route set with session updates. Let me know if it makes the difference.
The same scenario (callee wants sessiontimers refreshed by the uac) works kind of. ACKs are routed correctly but:
-Route to the callee has trailing nulls (starting from the first ACK to the callee (packet 7 in pcap)) -At random (seen it happen in both testcalls) the Via header to the caller is borked (packet 77) in the 200 OK to the caller. Someone (not the callee for sure, and doesn't look like a packet from the caller) is generating a CANCEL (packet 95) and next the caller will hangup. -When enabling topos module, kamailio leaks memory like crazy at a rate of about 1 GB in 2 hours without any calls (only OPTIONS and replies)
BTW might any of these be because of the way I test? I update the git tree and copy the topos module stuff into my 4.2 tree (debian source package), build the package, and copy only topos.so to live.
On 02/09/16 12:33, Daniel Tryba wrote:
[...] -When enabling topos module, kamailio leaks memory like crazy at a rate of about 1 GB in 2 hours without any calls (only OPTIONS and replies)
What kind of memory is leaking? Private (pkg), shared or system memory?
Cheers, Daniel
On Fri, Sep 02, 2016 at 02:01:09PM +0200, Daniel-Constantin Mierla wrote:
-When enabling topos module, kamailio leaks memory like crazy at a rate of about 1 GB in 2 hours without any calls (only OPTIONS and replies)
What kind of memory is leaking? Private (pkg), shared or system memory?
System memory, the systems OOM killer is triggered. I have looked at the "kamcmd mod.stats all shm" stats and they don't change much. I'll have to look into memory debugging before I can give more info.
On 02/09/16 15:19, Daniel Tryba wrote:
On Fri, Sep 02, 2016 at 02:01:09PM +0200, Daniel-Constantin Mierla wrote:
-When enabling topos module, kamailio leaks memory like crazy at a rate of about 1 GB in 2 hours without any calls (only OPTIONS and replies)
What kind of memory is leaking? Private (pkg), shared or system memory?
System memory, the systems OOM killer is triggered. I have looked at the "kamcmd mod.stats all shm" stats and they don't change much. I'll have to look into memory debugging before I can give more info.
Interesting, grepping inside the topos module doesn't reveal any system malloc being used... maybe a side effect in other part, needs more debugging. Maybe you can test with valgrind.
Cheers, Daniel
On Mon, Sep 05, 2016 at 09:15:41AM +0200, Daniel-Constantin Mierla wrote:
System memory, the systems OOM killer is triggered. I have looked at the "kamcmd mod.stats all shm" stats and they don't change much. I'll have to look into memory debugging before I can give more info.
Interesting, grepping inside the topos module doesn't reveal any system malloc being used... maybe a side effect in other part, needs more debugging. Maybe you can test with valgrind.
Haven't gotten around to really debugging it, but since I disabled the nathelpers sipping there was apparently no leak. Enabling sippinging again and there is a noticeable increase in memory over time.
On 02/09/16 12:33, Daniel Tryba wrote:
On Thu, Sep 01, 2016 at 03:07:46PM +0200, Daniel-Constantin Mierla wrote:
I pushed a new commit, aiming to avoid overwriting record route set with session updates. Let me know if it makes the difference.
The same scenario (callee wants sessiontimers refreshed by the uac) works kind of. ACKs are routed correctly but:
-Route to the callee has trailing nulls (starting from the first ACK to the callee (packet 7 in pcap)) [...]
Couldn't spot the real reason to have those zeors in the route value, I added some trimming before inserting the header to see if it's from there. Can you give another try with latest master?
Cheers, Daniel
On Tue, Sep 06, 2016 at 12:53:35PM +0200, Daniel-Constantin Mierla wrote:
-Route to the callee has trailing nulls (starting from the first ACK to the callee (packet 7 in pcap)) [...]
Couldn't spot the real reason to have those zeors in the route value, I added some trimming before inserting the header to see if it's from there.
Maybe something related with a tcp endpoint to udp conversion on the loadbalancer with enable_double_rr enabled?
Can you give another try with latest master?
I'll give it a try asap.
On Tue, Sep 06, 2016 at 12:53:35PM +0200, Daniel-Constantin Mierla wrote:
-Route to the callee has trailing nulls (starting from the first ACK to the callee (packet 7 in pcap)) [...]
Couldn't spot the real reason to have those zeors in the route value, I added some trimming before inserting the header to see if it's from there. Can you give another try with latest master?
Zeros are fixed, also I'm not seeing any broken Via anymore (so far in 4 test calls > 30m).
But I found a new problem instead. In attached pcap, the caller hangsup. It sends a BYE (packet 152) to sip:atpsh-57d1682c-5030-8@185.61.68.106 But that isn't routed to the correct destination. This only happens after some time (after session timers kick in), a short call (<45s) is disconnected properly.
BYE sip:109.235.32.57;r2=on;lr SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK2b6e.361405330d3447114a61eeb9ea603166.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK2b6e.4b6ac03027a65b62fbc89dbba78d0f1a.0 Max-Forwards: 68 From: sip:+31402938662@109.235.35.42;tag=as2305c39a To: sip:+31407110385@sipcluster2.pocos.nl;tag=as2b8ad5c1 Call-ID: 5039a1370a53ec320a3b35e871e34441@109.235.35.42:5060 CSeq: 103 BYE Reason: Q.850;cause=16 Content-Length: 0 Contact: sip:btpsh-57d1682c-5030-7@185.61.68.106
The RURI is broken, the Contact is not rewritten to the callees original Contact but topos variant, and the Vias are reconstructed.
On 31/08/16 15:56, Daniel Tryba wrote:
I'll try to test all call scenarios tomorrow.
Thanks for the quick fix.
[...]
BTW syslog is getting spammed with ERROR: topos [tps_storage.c:874]: tps_storage_load_dialog(): no dlg uuid provided these are related to locally generated OPTIONS by the dispatcher and nathelper modules.
Good catch, just pushed a commit to make that message a dbg.
Cheers, Daniel
-
Daniel Tryba -
Daniel-Constantin Mierla