Hello,
We have the following setup on Kamailio 5.3.7 (x86_64/linux) and I am trying to use topos module on Kamailio2 in order to hide our topology but, mostly to reduce the invite size as most of the times we have fragmentation on invites from Kamailio1 as Kamailio1 it adds 2 record-routes and two via as it handles TLS from one side and UDP on the other side and we have found no wat to avoid all this info even with topos enabled on Kamailio1 there is no change on this.
UA (OverTLS) -> Kamailio1 (Over UDP)-> Kamailio2 (Over UDP)-> Provider UA :50.50.50.50:5065 (TLS) Kamailio1: 170.170.170.210:5061 (TLS),170.170.170.210:5060 (UDP) Kamailio2: 170.170.170.170:5060 (UDP) Provider: 200.200.200.193:5060 (UDP)
Kamailio1 does not run topos.
Kamailio2 does run topos and rr with bellow settings: # ------ topos ------ modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3) modparam("topos", "contact_host", " sbc181.myserver.com")
# ----- rr params ----- # set next param to 1 to add value to ;lr param (helps with some UAs) modparam("rr", "enable_full_lr", 0) modparam("rr", "ignore_sips", 1) # 0 = do not append from tag to the RR, 0 = append from tag to the RR modparam("rr", "append_fromtag", 0) # dual RR 0 = No, 1 = Yes when needed 2 = Always modparam("rr", "enable_double_rr", 0)
The problem is that on the invite from Kamailio2 to provider, topos adds only VIA kai new contact. No record route at all. So the provider sends multiple 200 ok SDPs to wrong IPs. If I disable topos module on kamailio2 everything works fine except that we have huge invite as another VIA and another record route is added having now three of each and fragmentation is present.
*Invite from Kamailio1 to Kamailio2* ------------------------------------------------- 2021/09/08 21:41:57.698823 170.170.170.210:5060 -> 170.170.170.181:5060 INVITE sip:1234567890@sip.myserver.com:5060 SIP/2.0 Record-Route: sip:170.170.170.210;r2=on;lr;ftag=1b973153-4034-4480-89d3-c47b411bd81e;vsf=AAAAAFpUAgEBBwEAAXABAG5BR0EAQUBCZXJ2b2ljZS5ldQ--;vst=AAAAAAoMDgsBBQcGAgIAdENbQG4AFxNUXAUaGQYXWAocY2UuZXU-;did=ff2.96a;nat=yes Record-Route: sip:170.170.170.210:5061 ;transport=tls;r2=on;lr;ftag=1b973153-4034-4480-89d3-c47b411bd81e;vsf=AAAAAFpUAgEBBwEAAXABAG5BR0EAQUBCZXJ2b2ljZS5ldQ--;vst=AAAAAAoMDgsBBQcGAgIAdENbQG4AFxNUXAUaGQYXWAocY2UuZXU-;did=ff2.96a;nat=yes Via: SIP/2.0/UDP 170.170.170.210;branch=z9hG4bKd703.e095cdba1da1a4b1599119c9135b7838.0;i=8eb41 Via: SIP/2.0/TLS 50.50.50.50:5065 ;received=50.50.50.50;rport=31090;branch=z9hG4bKPj9196e5f9-977c-4a53-a4c0-c0ab82b095da;alias From: 987654321 <sip: 987654321@sip.myserver.com
;tag=1b973153-4034-4480-89d3-c47b411bd81e
To: <sip: 1234567890@sip.myserver.com> Contact: sip:customer1@50.50.50.50:5065 ;transport=TLS;alias=50.50.50.50~31090~3 Call-ID: cd64414e-77d5-45b4-a52d-74ec7fb5c7ef CSeq: 15776 INVITE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 69 Content-Type: application/sdp Content-Length: 231 P-Asserted-Identity: <sip: 987654321@sip.myserver.com>
v=0 o=- 391641952 391641952 IN IP4 170.170.170.216 s=Asterisk c=IN IP4 170.170.170.216 t=0 0 m=audio 29478 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=sendrecv a=rtcp:29479 a=ptime:20
*Invite from Kamailio2 to Provider* ------------------------------------------------- 2021/09/08 21:41:57.715881 170.170.170.181:5060 -> 200.200.200.193:5060 INVITE sip: 1234567890@sbc181.myserver.com:5060 SIP/2.0 Via: SIP/2.0/UDP 170.170.170.181;branch=z9hG4bKd703.d45db1fd910c43c5e7c4f8711a5fca92.0 From: 987654321 <sip: 987654321@sip.myserver.com
;tag=1b973153-4034-4480-89d3-c47b411bd81e
To: sip:1234567890@sip.myserver.com Call-ID: cd64414e-77d5-45b4-a52d-74ec7fb5c7ef CSeq: 15776 INVITE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 68 Content-Type: application/sdp Content-Length: 231 P-Asserted-Identity: <sip: 987654321@sip.myserver.com> Contact: sip:btpsh-c9-613903ef-21d75-1@sbc181.myserver.com
v=0 o=- 391641952 391641952 IN IP4 170.170.170.184 s=Asterisk c=IN IP4 170.170.170.184 t=0 0 m=audio 11450 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=sendrecv a=rtcp:11451 a=ptime:20
*Bellow you can see the flow* ---------------------------------------- 170.170.170.210:5060 170.170.170.170:5060 200.200.200.193:5060 qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqq 21:41:57.698823 x INVITE (SDP) x x +0.003788 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x 21:41:57.702611 x 100 trying -- your call is x x +0.013270 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:41:57.715881 x x INVITE (SDP) x +0.018529 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:41:57.734410 x x 100 Trying x +0.804083 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:41:58.538493 x x 183 Session Progress (SDP) x +0.014557 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:41:58.553050 x 183 Session Progress (SDP) x x +0.483907 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:41:59.036957 x x 183 Session Progress (SDP) x +0.012009 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:41:59.048966 x 183 Session Progress (SDP) x x +0.988036 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:00.037002 x x 183 Session Progress (SDP) x +0.010960 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:00.047962 x 183 Session Progress (SDP) x x +1.989085 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:02.037047 x x 183 Session Progress (SDP) x +0.010947 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:02.047994 x 183 Session Progress (SDP) x x +3.989064 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:06.037058 x x 183 Session Progress (SDP) x +0.008860 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:06.045918 x 183 Session Progress (SDP) x x +1.178240 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.224158 x CANCEL x x +0.002725 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x 21:42:07.226883 x x CANCEL x +0.000372 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:42:07.227255 x 200 canceling x x +0.016902 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.244157 x x 200 OK x +0.004590 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:42:07.248747 x x 487 Request Terminated x +0.003547 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:42:07.252294 x x ACK x +0.003737 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:42:07.256031 x 487 Request Terminated x x +0.001161 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.257192 x ACK x x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x
TCP is out of question from the provider. Any help to use topos or any other module to reduce the size of our invites to avoid fragmentation will be much appreciated!
Regards, Angelo
Hello,
topos does not add any Record-Route, that's the idea, to have the INVITE look like being initiated by Kamailio. Replies come back based on Via and requests within dialog based on Contact.
The Record-Route has nothing to do with replies routing anyhow. It is all about Via.
Is Kamailio behind nat/firewall?
Cheers, Daniel
On 08.09.21 21:41, Angelo Sipper wrote:
Hello,
We have the following setup on Kamailio 5.3.7 (x86_64/linux) and I am trying to use topos module on Kamailio2 in order to hide our topology but, mostly to reduce the invite size as most of the times we have fragmentation on invites from Kamailio1 as Kamailio1 it adds 2 record-routes and two via as it handles TLS from one side and UDP on the other side and we have found no wat to avoid all this info even with topos enabled on Kamailio1 there is no change on this.
UA (OverTLS) -> Kamailio1 (Over UDP)-> Kamailio2 (Over UDP)-> Provider UA :50.50.50.50:5065 http://50.50.50.50:5065/ (TLS) Kamailio1: 170.170.170.210:5061 http://170.170.170.210:5061/ (TLS),170.170.170.210:5060 http://170.170.170.210:5060/ (UDP) Kamailio2: 170.170.170.170:5060 http://170.170.170.170:5060/ (UDP) Provider: 200.200.200.193:5060 http://200.200.200.193:5060/ (UDP)
Kamailio1 does not run topos.
Kamailio2 does run topos and rr with bellow settings: # ------ topos ------ modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3) modparam("topos", "contact_host", " sbc181.myserver.com http://sbc181.myserver.com/")
# ----- rr params ----- # set next param to 1 to add value to ;lr param (helps with some UAs) modparam("rr", "enable_full_lr", 0) modparam("rr", "ignore_sips", 1) # 0 = do not append from tag to the RR, 0 = append from tag to the RR modparam("rr", "append_fromtag", 0) # dual RR 0 = No, 1 = Yes when needed 2 = Always modparam("rr", "enable_double_rr", 0)
The problem is that on the invite from Kamailio2 to provider, topos adds only VIA kai new contact. No record route at all. So the provider sends multiple 200 ok SDPs to wrong IPs. If I disable topos module on kamailio2 everything works fine except that we have huge invite as another VIA and another record route is added having now three of each and fragmentation is present.
*Invite from Kamailio1 to Kamailio2*
2021/09/08 21:41:57.698823 170.170.170.210:5060 http://170.170.170.210:5060/ -> 170.170.170.181:5060 http://170.170.170.181:5060/ INVITE sip:1234567890@sip.myserver.com:5060 http://sip:1234567890@sip.myserver.com:5060/ SIP/2.0 Record-Route: sip:170.170.170.210;r2=on;lr;ftag=1b973153-4034-4480-89d3-c47b411bd81e;vsf=AAAAAFpUAgEBBwEAAXABAG5BR0EAQUBCZXJ2b2ljZS5ldQ--;vst=AAAAAAoMDgsBBQcGAgIAdENbQG4AFxNUXAUaGQYXWAocY2UuZXU-;did=ff2.96a;nat=yes Record-Route: sip:170.170.170.210:5061;transport=tls;r2=on;lr;ftag=1b973153-4034-4480-89d3-c47b411bd81e;vsf=AAAAAFpUAgEBBwEAAXABAG5BR0EAQUBCZXJ2b2ljZS5ldQ--;vst=AAAAAAoMDgsBBQcGAgIAdENbQG4AFxNUXAUaGQYXWAocY2UuZXU-;did=ff2.96a;nat=yes Via: SIP/2.0/UDP 170.170.170.210;branch=z9hG4bKd703.e095cdba1da1a4b1599119c9135b7838.0;i=8eb41 Via: SIP/2.0/TLS 50.50.50.50:5065;received=50.50.50.50;rport=31090;branch=z9hG4bKPj9196e5f9-977c-4a53-a4c0-c0ab82b095da;alias From: 987654321 <sip: 987654321@sip.myserver.com mailto:987654321@sip.myserver.com>;tag=1b973153-4034-4480-89d3-c47b411bd81e To: <sip: 1234567890@sip.myserver.com mailto:1234567890@sip.myserver.com> Contact: sip:customer1@50.50.50.50:5065;transport=TLS;alias=50.50.50.50~31090~3 Call-ID: cd64414e-77d5-45b4-a52d-74ec7fb5c7ef CSeq: 15776 INVITE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 69 Content-Type: application/sdp Content-Length: 231 P-Asserted-Identity: <sip: 987654321@sip.myserver.com mailto:987654321@sip.myserver.com>
v=0 o=- 391641952 391641952 IN IP4 170.170.170.216 s=Asterisk c=IN IP4 170.170.170.216 t=0 0 m=audio 29478 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=sendrecv a=rtcp:29479 a=ptime:20
*Invite from Kamailio2 to Provider*
2021/09/08 21:41:57.715881 170.170.170.181:5060 http://170.170.170.181:5060/ -> 200.200.200.193:5060 http://200.200.200.193:5060/ INVITE sip: 1234567890@sbc181.myserver.com:5060 http://1234567890@sbc181.myserver.com:5060/ SIP/2.0 Via: SIP/2.0/UDP 170.170.170.181;branch=z9hG4bKd703.d45db1fd910c43c5e7c4f8711a5fca92.0 From: 987654321 <sip: 987654321@sip.myserver.com mailto:987654321@sip.myserver.com>;tag=1b973153-4034-4480-89d3-c47b411bd81e To: <sip:1234567890@sip.myserver.com mailto:sip%3A1234567890@sip.myserver.com> Call-ID: cd64414e-77d5-45b4-a52d-74ec7fb5c7ef CSeq: 15776 INVITE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 68 Content-Type: application/sdp Content-Length: 231 P-Asserted-Identity: <sip: 987654321@sip.myserver.com mailto:987654321@sip.myserver.com> Contact: <sip:btpsh-c9-613903ef-21d75-1@sbc181.myserver.com mailto:sip%3Abtpsh-c9-613903ef-21d75-1@sbc181.myserver.com>
v=0 o=- 391641952 391641952 IN IP4 170.170.170.184 s=Asterisk c=IN IP4 170.170.170.184 t=0 0 m=audio 11450 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=sendrecv a=rtcp:11451 a=ptime:20
*Bellow you can see the flow*
170.170.170.210:5060 http://170.170.170.210:5060/ 170.170.170.170:5060 http://170.170.170.170:5060/ 200.200.200.193:5060 http://200.200.200.193:5060/ qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqq 21:41:57.698823 x INVITE (SDP) x x +0.003788 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x 21:41:57.702611 x 100 trying -- your call is x x +0.013270 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:41:57.715881 x x INVITE (SDP) x +0.018529 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:41:57.734410 x x 100 Trying x +0.804083 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:41:58.538493 x x 183 Session Progress (SDP) x +0.014557 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:41:58.553050 x 183 Session Progress (SDP) x x +0.483907 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:41:59.036957 x x 183 Session Progress (SDP) x +0.012009 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:41:59.048966 x 183 Session Progress (SDP) x x +0.988036 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:00.037002 x x 183 Session Progress (SDP) x +0.010960 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:00.047962 x 183 Session Progress (SDP) x x +1.989085 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:02.037047 x x 183 Session Progress (SDP) x +0.010947 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:02.047994 x 183 Session Progress (SDP) x x +3.989064 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:06.037058 x x 183 Session Progress (SDP) x +0.008860 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:06.045918 x 183 Session Progress (SDP) x x +1.178240 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.224158 x CANCEL x x +0.002725 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x 21:42:07.226883 x x CANCEL x +0.000372 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:42:07.227255 x 200 canceling x x +0.016902 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.244157 x x 200 OK x +0.004590 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:42:07.248747 x x 487 Request Terminated x +0.003547 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:42:07.252294 x x ACK x +0.003737 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:42:07.256031 x 487 Request Terminated x x +0.001161 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.257192 x ACK x x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x
TCP is out of question from the provider. Any help to use topos or any other module to reduce the size of our invites to avoid fragmentation will be much appreciated!
Regards, Angelo
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Angelo Sipper -
Daniel-Constantin Mierla