RTCWeb Parthasarathi. Ravindran Internet-Draft Uwe. Rauschenbach Intended status: Standards Track Elangovan. Manickam Expires: December 14, 2013 Nokia Siemens Networks June 12, 2013 Offer & Answer interworking between JSEP & SIP draft-partha-rtcweb-jsep-sip-00 Abstract Real time communcation Web (RTCWeb) workgroup defines the real time commmunication using JavaScript Session establishment protocol (JSEP) as an offer/answer mechanism. Session Initiation protocol (SIP) is IETF defined and well deployed protocol for real time communication. This document provides offer & answer interworking between JSEP and SIP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 14, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Ravindran, et al. Expires December 14, 2013 [Page 1] Internet-Draft O/A Interworking between JSEP & SIP June 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SIP and JSEP offer/answer mapping architecture . . . . . . . . 4 5. JSEP offer/answer to SIP offer/answer mapping . . . . . . . . 4 5.1. Basic JSEP session mapping . . . . . . . . . . . . . . . . 4 5.2. Early media mapping . . . . . . . . . . . . . . . . . . . 5 5.3. Re-INVITE mapping . . . . . . . . . . . . . . . . . . . . 6 5.4. Offer JSEP- SIP Offer Race condition handling . . . . . . 6 5.5. JSEP to SIP serial forking . . . . . . . . . . . . . . . . 7 5.6. JSEP to SIP Parallel forking . . . . . . . . . . . . . . . 8 6. SIP offer/answer to JSEP offer/answer mapping . . . . . . . . 9 6.1. Basic SIP-JSEP session mapping . . . . . . . . . . . . . . 9 6.2. INVITE without SDP Offer to JSEP session mapping . . . . . 10 6.3. SIP Non-ICE to JSEP ICE handling . . . . . . . . . . . . . 10 6.4. JSEP ICE to SIP Non-ICE handling . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Ravindran, et al. Expires December 14, 2013 [Page 2] Internet-Draft O/A Interworking between JSEP & SIP June 2013 1. Introduction Real time communcation Web (RTCWeb) workgroup defines JavaScript Session establishment protocol (JSEP) [I-D.ietf-rtcweb-jsep] as an offer/answer mechanism. The transport to carry JSEP information shall be HTTP long polling [RFC6202] or WebSockets over TLS/TCP [RFC6455]. JSEP Offer/answer details shall be carried based on the application choice and some of the possible mechanism are REST or SIP or XMPP. HTTP based transport mechanism has the advantages of travering through all NAT and firewall. JSEP offer/answer focuses on the offer/answer between two browsers wherein the offer/answer related feature like parallel forking in SIP is not provided. Session Initiation protocol (SIP) [RFC3261] is IETF defined and well deployed protocol for real time communication. SIP offer/answer mechanism is based on [RFC3264] and few enhancements are done in the SIP layer. RTCWeb clients (browser) and SIP UA supports Session Description protocol (SDP)[RFC4566] as the media description protocol. In case of mapping between these two protocols, SDP shall be reused. SIP offer/answer supports the different RTP models [RFC3550] like RTP endpoint, RTP Mixer, RTP translator whereas JSEP supports RTP endpoint only. As there are difference betweeen SIP offer/answer and JSEP, there is a need of explicit mapping. This document provides the mapping between JSEP and SIP offer/answer mechanism. This mapping happens between SIP UA and RTCWeb entity which handles JSEP. RTCWeb entity in this document refers to the RTCWeb compliant browser or RTCWeb Server. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document only uses these key words when referencing normative statements in existing RFCs." 3. Definitions o RTCWeb entity : RTCWeb compliant browser or RTCWeb Server. o 18x response: 180 (ringing) or 183 (session progress) or any other response in the range of 180-189 Ravindran, et al. Expires December 14, 2013 [Page 3] Internet-Draft O/A Interworking between JSEP & SIP June 2013 4. SIP and JSEP offer/answer mapping architecture The mapping between SIP and JSEP offer/answer is the building block described in this document. This mapping happens between SIP UA and RTCWeb entity which handles JSEP. RTCWeb entity in this document refers to the RTCWeb compliant browser or RTCWeb Server. The following diagrams illustrate the possible JSEP-SIP mapping architecture. JSEP SIP RTCWeb Browser <------->RTCWeb Server + SIP UA <------> SIP UA Fig 1: JSEP-SIP mapping in RTCWeb Server In the above figure 1, JSEP-SIP mapping is done at RTCWeb server. JSEP shall be transported from RTCWeb browser to RTCWeb Server by any signaling mechanism SIP RTCWeb Browser + SIP UA<----------->RTCWeb Server + SIP UA/Proxy Fig 2: JSEP-SIP mapping in RTCWeb browser JSEP-SIP mapping shall be done at RTCWeb browser as shown in the above diagram. SIP shall be transported from RTCWeb browser to RTCWeb Server by SIP over WebSocket or any other signaling mechanism 5. JSEP offer/answer to SIP offer/answer mapping 5.1. Basic JSEP session mapping In RTCWeb browser, ICE is mandatorily supported. ICE calls for two offer/answer exchange wherein the initial offer indicates the set of ICE candidate pairs and the second offer/answer confirms the candidate pair which is used for the session. JSEP OFFER SHALL be mapped to INVITE with SDP and 200 OK with SDP SHALL be mapped to JSEP ANSWER. Ravindran, et al. Expires December 14, 2013 [Page 4] Internet-Draft O/A Interworking between JSEP & SIP June 2013 RTCWeb Browser JSEP-SIP GW SIP UA | | | |------OFFER--------->|--INVITE(OFFER)----->| | | | | |<-------100----------| | |<-------18x----------| | | | |<-----ANSWER---------|<----200 ANSWER------| | | | | |------ ACK---------->| | | | |-----OFFER2--------->|--RE-INVITE(OFFER2)->| | | | |<----ANSWER2---------|<---200 ANSWER-------| | | | | |----ACK------------->| Fig 3: Basic JSEP to SIP session mapping 5.2. Early media mapping In SIP, early dialog is established using PRACK [RFC3262] method and ICE negotiation (OFFER2) is triggered by UPDATE method [RFC3311] towards SIP UA. 18x (18x/183) response with SDP triggers the early media. SDP 200 for INVITE with Answer2 SHALLL be ignored towards JSEP side as the answer2 is forwarded as part of 200 for UPDATE with Answer2. RTCWeb Browser JSEP-SIP GW SIP UA | | | |------OFFER--------->|--INVITE(OFFER)----->| | | | | |<-------100----------| | | | |<-----ANSWER---------|<----18x ANSWER------| | | | | |-------PRACK-------->| | | | |-----OFFER2--------->|--UPDATE(OFFER2)---->| | | | |<----ANSWER2---------|<-200 UPDATE ANSWER2-| | | | | |<----200 ANSWER2-----| | | | | |------ ACK---------->| Ravindran, et al. Expires December 14, 2013 [Page 5] Internet-Draft O/A Interworking between JSEP & SIP June 2013 | | | Fig 4: Early media JSEP to SIP session mapping 5.3. Re-INVITE mapping RTCWeb Browser JSEP-SIP GW SIP UA | | | |<--Dialog is established with INV/200/ACK--| | | | |<-----OFFER----------|<--RE-INVITE(OFFER)--| | | | | |--------100--------->| | | | |------ANSWER-------->|-----200 ANSWER----->| | | | | |<----- ACK-----------| Fig 5: RE-INVITE mapping 5.4. Offer JSEP- SIP Offer Race condition handling It is possible for offer to be send by RTCWeb browser and SIP UA during the middle of the session. In [RFC3262], these race conditions are resolved using 491 response as shown below. Ravindran, et al. Expires December 14, 2013 [Page 6] Internet-Draft O/A Interworking between JSEP & SIP June 2013 RTCWeb Browser JSEP-SIP GW SIP UA | | | |<--Dialog is established with INV/200/ACK--| | | | |-----OFFER---------->|<--RE-INVITE(OFFER2)-| | | | | |--------491--------->| | | | | |<----- ACK-----------| | | | | |--RE-INVITE(OFFER1)->| | | | |<-----ANSWER---------|<-----200 ANSWER1----| | | | | |<----- ACK-----------| | | | |<-----OFFER2---------|<--RE-INVITE(OFFER2)-| | | | | |--------100--------->| | | | |------ANSWER2------->|-----200 ANSWER2---->| | | | | |<----- ACK-----------| Fig 6: RE-INVITE-JSEP OFFER race condition mapping 5.5. JSEP to SIP serial forking In case of SIP serial forking with ICE exchange, second offer MAY be required in case the candidate pair is changing from the default during the early dialog and such earlier dialog offer/answer exchange has to happen in dialog1 using UPDATE mechanism. When the second INVITE is forked from proxy towards the UA3, the final response 200 OK from UA3 is received with different SDP as Answer3. Answer3 has to be mapped as Offer 3 towards JSEP in JSEP-SIP gateway as JSEP completed offer-answer exchange already. Also, PRANSWER state in JSEP is not used as OFFER2 with ICE update is not possible within PRANSWER state. ANSWER4 SDP is same as ANSWER2, RE-INVITE towards UA shall be optimized or else RE-INVITE MUST be exchanged between JSEP- SIP GW to SIP-UA. Ravindran, et al. Expires December 14, 2013 [Page 7] Internet-Draft O/A Interworking between JSEP & SIP June 2013 RTCWeb Browser JSEP-SIPGW SIP Proxy SIP UA2 SIP UA3 | | | | | |--OFFER--->|--INVITE(OFFER)->|---INVITE1--->| | | | | OFFER | | | |<-----100--------| | | | | | | | |<-ANSWER---|<----18x ANSWER--|<-18x ANSWER--| | | | | | | | |--PRACK--------->|-----PRACK--->| | | | | | | |-OFFER2--->|--UPDATE OFFER2->|---> UDPATE-->| | | | | OFFER2 | | |<-ANSWER2--|<-200 UPDATE | | | | | ANSWER2----|<--- 200 | | | | | ANSWER2--| | | | | | | | | |-----INVITE2---------->| | | | OFFER | | |<-OFFER3---|<-200 INVITE-----|<---- 200 INVITE-------| | | ANSWER3 | ANSWER3 | | |-ANSWER4-->| |---- ACK-------------->| | |----BYE1-------->|---- BYE1---->| | | | | | | | |---ACK---------->| | | Fig 7: Serial Forking JSEP to SIP session mapping The assumption in Fig 5 is that ANSWER2 and ANSWER4 are same. In case they are different, there is a need of extra offer-answer between JSEP-SIP GW and SIP UA3 5.6. JSEP to SIP Parallel forking JSEP does not support SIP parallel forking currently and it is the application responsibility to achieve the same. As JSEP-SIPGW is the application in this document, SIP parallel forking SHALL be achieved as shown below. The point to be noted is that only one active RTP stream is possible in JSEP side and so, the other active RTP stream is updated as inactive using UPDATE offer/answer as shown in offer4. The rest of the callflow for parallel forking is same as SIP serial forking handling. Ravindran, et al. Expires December 14, 2013 [Page 8] Internet-Draft O/A Interworking between JSEP & SIP June 2013 RTCWeb Browser JSEP-SIPGW SIP Proxy SIP UA2 SIP UA3 | | | | | |--OFFER--->|--INVITE(OFFER)->|---INVITE1--->| | | | | OFFER | | | |<-----100--------| | | | | |-----INVITE2---------->| | | | OFFER | | | | | | | |<-ANSWER---|<----18x ANSWER--|<-18x ANSWER--| | | | | | | | |--PRACK--------->|-----PRACK--->| | | | | | | |-OFFER2--->|--UPDATE OFFER2->|---> UDPATE-->| | | | | OFFER2 | | |<-ANSWER2--|<-200 UPDATE |<--- 200------| | | | ANSWER2----| ANSWER2 | | | | | | | |<-OFFER3---|<--18x ANSWER3---|<-18x ANSWER3----------| | | | | | | |--UPDATE OFFER4->|---> UDPATE-->| | | | | OFFER4 | | | |--PRACK--------->|-----PRACK------------>| | | | | | | |<-200 UPDATE |<--- 200------| | | | ANSWER4----| ANSWER4 | | |-ANSWER5-->| | | | | | | | | | |<-200 ANSWER3----|<---- 200--------------| | | | ANSWER3 | | | | |---- ACK-------------->| | | |---- BYE1---->| | | | | | | | |---ACK---------->| | | Fig 8: Parallel Forking JSEP to SIP session mapping 6. SIP offer/answer to JSEP offer/answer mapping SIP specific offer/answer mechanism is defined in [RFC3261]. 6.1. Basic SIP-JSEP session mapping INVITE with SDP offer is the first message in SIP which maps to JSEP Offer. The user alert information is not part of JSEP, HTTP application specific extension shall indicate the user alert status to the interworking entity which shall be later mapped to 18x mapping Ravindran, et al. Expires December 14, 2013 [Page 9] Internet-Draft O/A Interworking between JSEP & SIP June 2013 without SDP. When RTCWeb user accepts the session, JSEP send ANSWER towards interworking entity and ANSWER will be mapped to 200 OK message in SIP. 6.2. INVITE without SDP Offer to JSEP session mapping It is possible in SIP that INVITE without SDP offer is the first message in SIP which has to initiate JSEP Offer from the client side. The mechanism by which JSEP offer initiate request between interworking entity and JSEP entity is outside the scope of the document. Once the JSEP offer is received in the interworking entity, it will be to 183 with offer towards UAC. PRACK with SDP answer is received, 6.3. SIP Non-ICE to JSEP ICE handling SIP does not mandate for ICE [RFC5245] whereas JSEP in RTCWeb has to have mandatorily ICE handling. So, SIP-JSEP interworking entity has to make sure ICE to non-ICE handling as well as SDP specific changes for these interworking. 6.4. JSEP ICE to SIP Non-ICE handling Most of the deployed SIP devices does not support ICE whereas JSEP in RTCWeb always requires ICE. So, the interworking JSEP ICE to SIP Non-ICE has to be handled in case JSEP-SIP gateway. This document does not mandates the mechanism for this interworking but provides one of the possible solution wherein ICE exchange is handled by JSEP- SIP GW and here how JSEP-SIP Gateway identify SIP UA does not support ICE is outside the scope of this document. Ravindran, et al. Expires December 14, 2013 [Page 10] Internet-Draft O/A Interworking between JSEP & SIP June 2013 RTCWeb Browser JSEP-SIP GW SIP UA | | | |-OFFER with | | | Candidate info-->|--INVITE(OFFER w/o | | | Candidate info)---->| | | | | |<-------100----------| | | | | |<-------18x----------| | | | |<----ANSWER with | | | candidate info-----|<----200 ANSWER------| | | | | |------ ACK---------->| | | | |-OFFER2 with | | | candidate info----->| | | | | |<-ANSWER2 with | | | candidate info-----| | | | | | | | Fig 9: Basic JSEP ICE to SIP Non-ICE session mapping 7. Security Considerations The security consideration of SIP UA and JSEP MUST be considered for the interworking functionality. There is no need of any other extra security considerations for this document. 8. IANA Considerations There is no IANA considerations for this draft. 9. Acknowledgement Thanks a lot to Thomas Belling, Mohamed Ibrahim Elias, Ramakrishnan PA, Janne K Suotula, Markus Isomaki, Ranjit Avasarala, Paul Kyzivat for their review comments 10. References Ravindran, et al. Expires December 14, 2013 [Page 11] Internet-Draft O/A Interworking between JSEP & SIP June 2013 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-03 (work in progress), February 2013. 10.2. Informative References [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, April 2011. [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session Initiation Protocol (SIP) Usage of the Offer/Answer Model", RFC 6337, August 2011. Ravindran, et al. Expires December 14, 2013 [Page 12] Internet-Draft O/A Interworking between JSEP & SIP June 2013 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [I-D.ietf-sipcore-sip-websocket] Castillo, I., Millan, J., and V. Pascual, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", draft-ietf-sipcore-sip-websocket-08 (work in progress), March 2013. Authors' Addresses Parthasarathi Ravindran Nokia Siemens Networks Bangalore, Karnataka India Email: partha@parthasarathi.co.in Uwe Rauschenbach Nokia Siemens Networks St Martin Strasse 76 Munich Germany Email: uwe.rauschenbach@nsn.com Elangovan Manickam Nokia Siemens Networks Bangalore, Karnataka India Email: elangovan.manickam@nsn.com Ravindran, et al. Expires December 14, 2013 [Page 13]