SIP over Websocketsdraft-ibc-sipcore-sip-websocket-01            IETF 83          SIPCORE WG   Paris, France - March 2012 ...
History• draft-ibc-rtcweb-sip-websocket-00  – defines the WS transport for SIP  – rtcweb not meant to standardize a signal...
Scope• Define behavior for a main use case  • WS transport between a UA (one that cannot listen for    inbound WS connecti...
Problem Statement• WS clients do not listen for incoming connections  – its the WS client that needs to open and maintain ...
Solution space• Option 1: normative language  – define the behavior for WS transport between a UA    (one that cannot list...
Next Steps• Address comments from the technical  reviews (along with editorial  improvements) and submit a new version• Ca...
Upcoming SlideShare
Loading in …5
×

IETF83 - SIP over Websockets

836 views
722 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
836
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

IETF83 - SIP over Websockets

  1. 1. SIP over Websocketsdraft-ibc-sipcore-sip-websocket-01 IETF 83 SIPCORE WG Paris, France - March 2012 Iñaki Baz Castillo José Luis Millán Victor Pascual 1
  2. 2. History• draft-ibc-rtcweb-sip-websocket-00 – defines the WS transport for SIP – rtcweb not meant to standardize a signaling protocol• draft-ibc-sipcore-sip-websocket-00 – WS transport applicability not limited to web browsers• draft-ibc-sipcore-sip-websocket-01 (current draft) – three technical reviews – so far all reviews and comments support this work – main discussion around outbound applicability• At least two known implementations – e.g. http://sip-on-the-web.aliax.net/ – and some other in the roadmap 2
  3. 3. Scope• Define behavior for a main use case • WS transport between a UA (one that cannot listen for inbound WS connections) and its first hop into the network• Unforeseen circumstances should be allowed • thats where innovation is born • explicitly call out in the document that we dont currently define behavior for – inter-intermediary websockets connections – clients with the ability to listen for inbound connections • future documents may choose to do so 3
  4. 4. Problem Statement• WS clients do not listen for incoming connections – its the WS client that needs to open and maintain the WS connection – the WS server shall use an existing WS connection towards the client• This is identical to the case where a SIP UA uses TCP behind a NAT, to communicate with its proxy – the SIP UA cannot receive incoming connections – communication with it must occur over the connection it opened to the SIP server• This is not a new problem and we have solutions in place 4
  5. 5. Solution space• Option 1: normative language – define the behavior for WS transport between a UA (one that cannot listen for connections) and its first hop into the network: both MUST use outbound• Option 2: non-normative language – refer to Outbound as the preferred mechanism, but there might be other alternatives• Option 3: do nothing – do not mention the issue at all 5
  6. 6. Next Steps• Address comments from the technical reviews (along with editorial improvements) and submit a new version• Call for WG adoption 6

×