Hi Alex,

Thank you, that worked. I was over complicating it in my script by doing many 
replacements.



On Tuesday, February 4th, 2025 at 7:38 PM, Alex Balashov via sr-users 
<sr-users@lists.kamailio.org> wrote:

> Yes, you can switch the schema:
> 
> if(proto == TLS)
> $ru = $(ru{s.replace,sips:,sip:});
> 
> -- Alex
> 
> > On Feb 4, 2025, at 2:35 PM, James Lipski via sr-users 
> > sr-users@lists.kamailio.org wrote:
> > 
> > Hello,
> > 
> > I have a kamailio installation where it's basically doing transport 
> > protocol translation. To go into more detail, I have a UA communicating 
> > over TLS towards kamailio/ and kamailio forwards the request to a 
> > freeswitch installation via UDP, so call-flow is as follows:
> > 
> > UA <-- (TLS) --> Kamailio <-- (UDP) --> Freeswitch
> > 
> > For the most part, this does work/ it's only when I use a UA that uses 
> > "sips:" as the schema instead of "sip:" where issues occur -- in my current 
> > topology, freeswitch has some weird behavior where it doesn't disconnect 
> > the call properly. At least based on my testing, I believe the issue is 
> > relating to the schema -- as the UA in question does have the ability to 
> > switch between schemas/ when using "sip:" instead of "sips:" over TLS, no 
> > issues with the same call-flow. In the event that I do come across a UA 
> > that doesn't have that ability, I was wondering if kamailio has the ability 
> > to switch schemas when it sends traffic over the UDP connection.
> > 
> > I'm able to replace most aspects of the packet with "sip:" however the only 
> > header which contains the "sips:" schema is the contact header. With this 
> > alone, it propagates to the B-leg side (UDP side) of the call; and will 
> > cause freeswitch to not disconnect calls properly.
> > 
> > I'm using the topos module to obfuscate my topology, not sure if that 
> > matters.
> > --------
> > 
> > For example, on the A-leg side of the call, kamailio receives this:
> > INVITE sips:12125551...@dev-sip.server.com:5061 SIP/2.0
> > Via: SIP/2.0/TLS 172.16.1.194:5061;branch=z9hG4bK236557042;rport;alias
> > From: sips:100000...@dev-sip.server.com;tag=444048970
> > To: sips:12125551...@dev-sip.server.com
> > Call-ID: 1326419916-506...@bhc.bg.b.bje
> > CSeq: 21 INVITE
> > Contact: sips:100000000@172.16.1.194:5061;transport=tls
> > Proxy-Authorization: Digest username="100000000", 
> > realm="dev-sip.server.com", nonce="Z6Ig0WeiH6Vdxtvej0I3XGCTUAEfh+0/", 
> > uri="sips:12125551...@dev-sip.server.com", 
> > response="43c1487d077db36a70fffdd1e25b3b52", algorithm=MD5
> > Max-Forwards: 70
> > User-Agent: Grandstream HT812 1.0.57.1
> > Supported: replaces, path, timer, eventlist
> > Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, 
> > UPDATE
> > Content-Type: application/sdp
> > Accept: application/sdp, application/dtmf-relay
> > Content-Length: 1034
> > 
> > v=0
> > o=100000000 8000 8000 IN IP4 172.16.1.194
> > s=SIP Call
> > c=IN IP4 172.16.1.194
> > t=0 0
> > m=audio 5004 RTP/SAVP 0 101
> > a=sendrecv
> > a=rtpmap:0 PCMU/8000
> > a=ptime:20
> > a=rtpmap:101 telephone-event/8000
> > a=crypto:1 AEAD_AES_256_GCM 
> > inline:UlX3PAjNBP/aQwtwyf5ymsfJciB+VdFxMElO5zLVooUqmcEzZ8YyQQk9stI=|2^32
> > 
> > ------------------------------------------------------
> > 
> > On the B-leg side of the call, kamailio forwards the following to 
> > freeswitch:
> > 
> > INVITE sip:12125551...@fs.server.com SIP/2.0
> > Via: SIP/2.0/UDP 
> > 10.64.52.113:5080;branch=z9hG4bK1552.89ec9666294034a5611f908f2a6a427e.0;i=f
> > From: "Test" sip:16461234...@dev-sip.server.com;tag=444048970
> > To: sip:12125551...@fs.server.com
> > Call-ID: 1326419916-506...@bhc.bg.b.bje
> > CSeq: 21 INVITE
> > Max-Forwards: 15
> > Supported: replaces, path, timer, eventlist
> > Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, 
> > UPDATE
> > Content-Type: application/sdp
> > Accept: application/sdp, application/dtmf-relay
> > Content-Length: 316
> > Contact: sips:btpsh-67a21ca2-2dbe86-1@10.64.52.113:5080
> > 
> > v=0
> > o=100000000 8000 8000 IN IP4 10.64.52.113
> > s=SIP Call
> > c=IN IP4 10.64.52.113
> > t=0 0
> > m=audio 13060 RTP/AVP 0 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:101 telephone-event/8000
> > a=sendrecv
> > a=ptime:20
> > 
> > --------------------------------------------------
> > 
> > As with the above, I was wondering if there is a way within kamailio to 
> > switch schemas on the b-leg side of this call example; specifically is 
> > there a way to update the contact header so it doesn't use the "sips:" 
> > schema when it traverses the UDP connection.
> > 
> > Thank you for you time.
> > __________________________________________________________
> > Kamailio - Users Mailing List - Non Commercial Discussions -- 
> > sr-users@lists.kamailio.org
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to 
> > the sender!
> 
> 
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
> 
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions -- 
> sr-users@lists.kamailio.org
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- 
sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!

Reply via email to