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
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
-------------------------------------------------
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
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
----------------------------------------
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