Native SIPS URI support in baresip

[SnowMaster12]

Hi,

I would like to discuss the possibility of adding native sips: URI support to baresip.

At the moment, baresip already supports SIP over TLS using accounts such as:

<sip:user@example.com;transport=tls>

This works well for SIP-over-TLS scenarios, but it is not exactly the same as native SIPS URI handling as described in RFC 3261 / RFC 5630.

The goal would be to support account definitions like:

<sips:user@example.com>;auth_user=user;auth_pass=secret

The main requirements I see are:

• preserve the sips: scheme instead of normalizing it to sip:
• force TLS transport whenever the account or target URI uses sips
• generate SIPS Contact headers for SIPS accounts and SIPS dialog-forming requests
• reject invalid combinations such as sips: with transport=udp or transport=tcp (obv)
• avoid automatic downgrade from sips to sip
• handle REGISTER, outgoing INVITE, incoming INVITE, 200 OK, ACK, BYE, re-INVITE/UPDATE and REFER consistently

A possible implementation approach could be:

1. Check whether re / libre URI parsing and encoding already preserve the sips scheme.
2. Add an account-level flag or scheme enum in baresip, for example:

   enum account_uri_scheme {
       ACCOUNT_URI_SCHEME_SIP,
       ACCOUNT_URI_SCHEME_SIPS
   };

3. Detect the scheme during account parsing.
4. Make local URI / Contact generation scheme-aware.
5. Force TLS transport for SIPS accounts and SIPS target URIs.
6. Add tests for REGISTER and INVITE generation using sips

The main question is whether this would be considered acceptable upstream, and where you would prefer the boundary between re / libre and baresip to be.

Would native SIPS support be welcome if implemented in this direction?

[SnowMaster12]

what do you think @cspiel1 @alfredh ?

[juha-h]

I have never liked SIPS, since its idea is that TLS should be used on every hop to the destination, but there is no way user can enforce it. So it doesn't give any benefit over ;transport=tls.