Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Kent Beck Effective Design
Next
Download to read offline and view in fullscreen.

0

Share

Download to read offline

SIP :: Half outbound (random notes)

Download to read offline

Trying to get a grip on what's needed for TLS UA-server connections in SIP.

Version 1.1 (update)

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

SIP :: Half outbound (random notes)

  1. 1. The problem with SIP outbound Why we need a half-outbound oej@edvina.net | 2016-06-10 | v1.1
  2. 2. 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
  3. 3. 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)
  4. 4. SIP Outbound • Presentation:
 http://www.slideshare.net/oej/sip2012-outbound • RFC 5626
 https://tools.ietf.org/html/rfc5626
  5. 5. RFC 3261 18.1.1
  6. 6. 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
  7. 7. 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?
  8. 8. 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
  9. 9. BUT DEVELOPERS DOESN’T WANT TO DO OUTBOUND.
  10. 10. Implementations
 known 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?
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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

Trying to get a grip on what's needed for TLS UA-server connections in SIP. Version 1.1 (update)

Views

Total views

614

On Slideshare

0

From embeds

0

Number of embeds

8

Actions

Downloads

5

Shares

0

Comments

0

Likes

0

×