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