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:12125551000@dev-sip.server.com:5061 SIP/2.0 Via: SIP/2.0/TLS 172.16.1.194:5061;branch=z9hG4bK236557042;rport;alias From: sips:100000000@dev-sip.server.com;tag=444048970 To: sips:12125551000@dev-sip.server.com Call-ID: 1326419916-5061-4@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:12125551000@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:12125551000@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:16461234567@dev-sip.server.com;tag=444048970 To: sip:12125551000@fs.server.com Call-ID: 1326419916-5061-4@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-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!