The problem with SIP outbound

Why we need a half-outboundoej@edvina.net | 2016-06-10 | v1.1

SIP problem• UAs move to TCP for TLS or for connection

handling over mobile networks

• UAs are behind NAT

• The server needs to reuse the connection to the client for outbound requests - typically an INVITE to the UA

• Connection reuse for clients is defined in SIP Outbound

SIP Outbound• Has a requirement of support of TWO flows

• SIP over websockets RFC ignores this silently

• Is a SIP extension, needs to be advertised

• Adds instance-ID and reg-ID and flow-token handling

• Only solves initial transactions, doesn’t handle connection changes during a dialog (not in scope)

SIP Outbound

• Presentation:http://www.slideshare.net/oej/sip2012-outbound

• RFC 5626https://tools.ietf.org/html/rfc5626

RFC 3261 18.1.1

What does this mean

• If the contact provided in a registration actually matches the connection (the IP/port used to set up the connection) the server can reuse the connection

• The URI needs to match

• The client needs to keep the connection open

What about TLS?• TLS adds a property to the matching of the URI -

verification of the other end.

• UA verify and validate connection to server

• But how does the server validate the connection to the UA?

SIPit tests• UAs provided contacts either with SIPS or with

“;transport=tls”

• UAs had no client cert

• Server can not reuse the connection

• “;transport=TLS” is deprecated in RFC 3261

• Only outbound can solve this

BUT DEVELOPERS DOESN’T WANT TO DO

OUTBOUND.

Implementationsknown to me

• Javascript SIP client libraries have half-outbound (it’s a requirement for websocket transport)

• Kamailio.org has outbound support in the server

• At least one UA at SIPit claimed support, but it was not tested

• Any others?

Ideas for half-outbound for TLS

• UA (client) opens TLS connection to server and validates cert

• Client indicates support for “connreuse” as “Supported:” extension in REGISTER request after connection is setup

• Server is allowed to ignore (as always)

• Client registers to AOR (and authenticates)

• If server answers 200 OK REGISTER with “Require: connreuse” the client is supposed to manage an open connection

• Server is allowed to reuse connection for outbound SIP requests to the AOR or associated GRUU (only after successful auth)

• Regardless of contact used in registration (maybe copy websockets with .invalid)

IDEA

Server handling

• If client indicated connreuse and TLS connection exist, reuse that for outbound requests

• If client close flow, delete registred contact and connection identifiers from location database

Contact URI

• No “;transport=tls” any more

• Maybe re-use “.invalid” contact URI’s from RFC 7118 (SIP over websockets)

• Require GRUU, Record-route or OUTBOUND to avoid peer-to-peer connection attempts

Differences compared to Outbound

• Only one connection required

• No extra indicators in contact

• No flow identifiers in headers

• No reg-id

• No failover between flows

• New connection can be setup mid-call and used for new in-dialog transactions

Simplification