### Description Some UAC (notably Aastra Phones) use the sips: uri scheme without ;transport=tls when TLS is being used. I observed kamailio 5.7.6 and most probably also 5.8.4 to insert the sips URI in the wrong Record-Route header causing replies not to reach the destination. #### Reproduction Find a UAC which uses the sips URI scheme when configured to use TLS. (AAstra IP Phones for example). Important: The Registration looks like this, contains no transport attribute but the sips scheme with port 5061 and a path pointing to the SBC. ``` "Contact" : { "Address" : "sips:315996608@157.161.4.237:5061", "CFlags" : 0, "CSeq" : 1446407115, "Call-ID" : "3abf8e6af6391e7b", "Expires" : 56, "Flags" : 0, "Instance" : "<urn:uuid:00000000-0000-1000-8000-00085D49FB42>", "KA-Roundtrip" : 0, "Keepalive" : 0, "Last-Keepalive" : 1735827284, "Last-Modified" : 1735827284, "Methods" : 16095, "Path" : "<sip:157.161.23.249;lr;r2=on>,<sip:157.161.23.249:5061;transport=tls;lr;r2=on>", "Q" : 0.44, "Received" : "[not set]", "Reg-Id" : 0, "Ruid" : "uloc-677695ae-20472d-23", "Server-Id" : 0, "Socket" : "udp:157.161.23.4:5060", "State" : "CS_DIRTY", "Tcpconn-Id" : -1, "User-Agent" : "Aastra 6869i/6.3.0.1020" } ``` Using this set-up: UAC (TLS) - Kamailio SBC (rtpengine / nat) udp - Kamailio Registrar udp - Core Infrastructure Call the UAC. Each hop is adding a Record-Route header which is then used by the UAC when creating a new transaction within the dialog. In this example: Transaction 1: CORE => UAC: INVITE 100rel supported UAC => CORE: 180 Ringing 100rel required --- Transaction 2: CORE => UAC: PRACK During the first transaction, Record-Route header are accumulated to indicate the Route set to be taken by the in-dialog PRACK request. In the INVITE, the UAC is presented with those Record-Route Header: The first two header are added by the SBC (IP .249) with r2=on to indicate the change from UDP to TLS The third header was added by the Registrar (IP .5) The fourth header was added by the Core (IP .2) ``` 02.01.2025 15:17:54.250 +01:00: 157.161.23.249:5061 -> 157.161.4.237:5061 INVITE sips:315996608@157.161.4.237:5061 SIP/2.0 Record-Route: <sips:157.161.23.249:5061;transport=tls;r2=on;lr;ftag=3944816274-1416360442> Record-Route: <sips:157.161.23.249;r2=on;lr;ftag=3944816274-1416360442> Record-Route: <sips:157.161.23.5;lr;ftag=3944816274-1416360442> Record-Route: <sip:157.161.23.2;lr;ftag=3944816274-1416360442;did=e77.89e5> ``` UAC is ringing: ``` 02.01.2025 15:17:54.368 +01:00: 157.161.4.237:5061 -> 157.161.23.249:5061 SIP/2.0 180 Ringing Via: SIP/2.0/TLS 157.161.23.249:5061;branch=z9hG4bK5b72.d42e9bf4e341f690d8b383a0a96edeb3.0 Via: SIP/2.0/UDP 157.161.23.5;rport=5060;branch=z9hG4bK5b72.621bba23d60b529f876b92bf2ab718de.0 Via: SIP/2.0/UDP 157.161.23.2;branch=z9hG4bK5b72.2d88c4e6630f19da5ae24efb523564bf.0 Via: SIP/2.0/UDP 157.161.10.230:5060;branch=z9hG4bK100567609d7e7e9517ddfb1eaa7d684c Record-Route: <sips:157.161.23.249:5061;transport=tls;r2=on;lr;ftag=3944816274-1416360442>, <sips:157.161.23.249;r2=on;lr;ftag=3944816274-1416360442>, <sips:157.161.23.5;lr;ftag=3944816274-1416360442>, <sip:157.161.23.2;lr;ftag=3944816274-1416360442;did=e77.89e5> [...] Contact: "Somebody" <sips:315996608@157.161.4.237:5061>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D49FB42>" ``` Origin of call takes this Record-Route to create the source Route header for new PRACK transaction: ``` 02.01.2025 15:17:54.393 +01:00: 157.161.10.230:5060 -> 157.161.23.2:5060 PRACK sips:315996608@157.161.4.237:5061 SIP/2.0 Max-Forwards: 66 Route: <sip:157.161.23.2;lr;ftag=3944816274-1416360442;did=e77.89e5> Route: <sips:157.161.23.5;lr;ftag=3944816274-1416360442> Route: <sips:157.161.23.249;r2=on;lr;ftag=3944816274-1416360442> Route: <sips:157.161.23.249:5061;transport=tls;r2=on;lr;ftag=3944816274-1416360442> RAck: 1 1 INVITE ``` According to this route set, the call shall be routed from 157.161.23.2 to 157.161.23.5 via 'sips' This fails as there is no TLS socket bound between those two instances. `prepare_new_uac(): can't fwd to af 2, proto 3 (no corresponding listening socket)` IMHO the issue is caused by the wrong URI scheme (sips instead of sip) being used when the registrar is adding it's Record-Route header. (And maybe also by the SBC when adding the double (r2=on) RR to indicate the change of transport. I suspect this happens, because the UAC has registered it's contact with the sips uri scheme. Repeating the same situation with an UAC which registers a sip:user@domain:5061;transport=tls URI when using TLS demonstrates this works fine. It only happens when an UAC uses the sips URI scheme. If any more information is required like a SIP trace of the issue, I am glad to provide it. -Benoît- -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4092 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/issues/4092(a)github.com&gt;