[SR-Users] Topos does not add record-route on invite
Daniel-Constantin Mierla
miconda at gmail.com
Thu Sep 9 08:14:27 CEST 2021
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 at 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 at sip.myserver.com
> <mailto:987654321 at sip.myserver.com>>;tag=1b973153-4034-4480-89d3-c47b411bd81e
> To: <sip: 1234567890 at sip.myserver.com
> <mailto:1234567890 at sip.myserver.com>>
> Contact:
> <sip:customer1 at 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 at sip.myserver.com
> <mailto:987654321 at 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 at 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 at sip.myserver.com
> <mailto:987654321 at sip.myserver.com>>;tag=1b973153-4034-4480-89d3-c47b411bd81e
> To: <sip:1234567890 at sip.myserver.com
> <mailto:sip%3A1234567890 at 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 at sip.myserver.com
> <mailto:987654321 at sip.myserver.com>>
> Contact: <sip:btpsh-c9-613903ef-21d75-1 at sbc181.myserver.com
> <mailto:sip%3Abtpsh-c9-613903ef-21d75-1 at 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 at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210909/a4cd83fa/attachment.htm>
More information about the sr-users
mailing list