RTCWeb Parthasarathi. Ravindran Internet-Draft Uwe. Rauschenbach Intended status: Standards Track Elangovan. Manickam Expires: April 24, 2014 Nokia Solutions and Networks October 21, 2013 Offer & Answer interworking between JSEP & SIP draft-partha-rtcweb-jsep-sip-01 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 April 24, 2014. 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 April 24, 2014 [Page 1] Internet-Draft O/A Interworking between JSEP & SIP October 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 . . . . . . . . . . . . . . 10 6.2. INVITE without SDP Offer to JSEP session mapping . . . . . 10 6.3. SIP Non-ICE to JSEP ICE handling . . . . . . . . . . . . . 10 6.4. JSEP to SIP Trickle-ICE handling . . . . . . . . . . . . . 10 6.5. JSEP ICE to SIP Non-ICE handling . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Ravindran, et al. Expires April 24, 2014 [Page 2] Internet-Draft O/A Interworking between JSEP & SIP October 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 April 24, 2014 [Page 3] Internet-Draft O/A Interworking between JSEP & SIP October 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 April 24, 2014 [Page 4] Internet-Draft O/A Interworking between JSEP & SIP October 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. ICE negotiation leads to OFFER2 from RTCWeb browser and it is triggered using 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 INVITE ANSWER2-| | | | | |------ ACK---------->| Ravindran, et al. Expires April 24, 2014 [Page 5] Internet-Draft O/A Interworking between JSEP & SIP October 2013 | | | Fig 4: Early media JSEP to SIP session mapping PRANSWER state in JSEP is not used during ANSWER in the above callflow as OFFER2 is not allowed as per PRANSWER state in JSEP. OFFER in PRANSWER is an open item in JSEP. 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 April 24, 2014 [Page 6] Internet-Draft O/A Interworking between JSEP & SIP October 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 and it is an open item in JSEP. 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 April 24, 2014 [Page 7] Internet-Draft O/A Interworking between JSEP & SIP October 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 responsibility of the application to achieve the same. As JSEP-SIPGW is the application in this document, SIP parallel forking can be achieved as shown below. The point to be noted is that only one active RTP stream is possible in JSEP side for a given single m-line from JSEP offer 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 April 24, 2014 [Page 8] Internet-Draft O/A Interworking between JSEP & SIP October 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 The assumption in Fig 8 is that ANSWER2 and ANSWER5 are same. In case they are different, there is a need of extra offer-answer between JSEP-SIP GW and SIP UA3 6. SIP offer/answer to JSEP offer/answer mapping SIP specific offer/answer mechanism is defined in [RFC3261]. Ravindran, et al. Expires April 24, 2014 [Page 9] Internet-Draft O/A Interworking between JSEP & SIP October 2013 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 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 to SIP Trickle-ICE handling Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is a ICE extension mechanism wherein the candidates can be exchanged incrementally. This would allow ICE agents to exchange host candidates as soon as a session has been initiated. Connectivity checks for a media stream would also start as soon as the first candidates for that stream have become available. Ravindran, et al. Expires April 24, 2014 [Page 10] Internet-Draft O/A Interworking between JSEP & SIP October 2013 RTCWeb Browser JSEP-SIP GW SIP UA | | | |-OFFER with | | | Candidate info-->|--INVITE(OFFER with | | | Candidate info)---->| | | | | |<-------100----------| | | | |<----ANSWER with-----|<--18x with initial | | initial candidate | candidate info-----| | info | | | |--PRACK------------->| | | | |<---OFFER2 with------|<---UPDATE with------| | complete candidate | complete candidate | | info | info OFFER2 | | | | |----ANSWER2 with---->|-----200 with------->| | updated candidate |updated candidate | | info | info ANSWER2 | | | | | |<----200 INVITE------| | | | | |------ ACK---------->| | | | Fig 9: Basic JSEP to SIP Trickle-ICE session mapping In case 200 OK with INVITE has different OFFER, the extra offer/ answer will be exchanged. This draft does not use "INFO" mechanism mentioned in [I-D.ivov-mmusic-trickle-ice-sip] as it leads to the race condition between INFO and UPDATE from JSEP side 6.5. 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 April 24, 2014 [Page 11] Internet-Draft O/A Interworking between JSEP & SIP October 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 10: Basic JSEP ICE to SIP Non-ICE session mapping Here, RE-INVITE is not triggered for OFFER2 as the update is related to the selected candidate pair only and there is no other SDP change 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 Ravindran, et al. Expires April 24, 2014 [Page 12] Internet-Draft O/A Interworking between JSEP & SIP October 2013 10. References 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-04 (work in progress), September 2013. [I-D.rescorla-mmusic-ice-trickle] Rescorla, E., Uberti, J., and E. Ivov, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-rescorla-mmusic-ice-trickle-01 (work in progress), October 2012. Ravindran, et al. Expires April 24, 2014 [Page 13] Internet-Draft O/A Interworking between JSEP & SIP October 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. [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-09 (work in progress), June 2013. [I-D.ivov-mmusic-trickle-ice-sip] Ivov, E., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", draft-ivov-mmusic-trickle-ice-sip-01 (work in progress), October 2013. Authors' Addresses Parthasarathi Ravindran Nokia Solutions and Networks Bangalore, Karnataka India Email: partha@parthasarathi.co.in Uwe Rauschenbach Nokia Solutions and Networks St Martin Strasse 76 Munich Germany Email: uwe.rauschenbach@nsn.com Ravindran, et al. Expires April 24, 2014 [Page 14] Internet-Draft O/A Interworking between JSEP & SIP October 2013 Elangovan Manickam Nokia Solutions and Networks Bangalore, Karnataka India Email: elangovan.manickam@nsn.com Ravindran, et al. Expires April 24, 2014 [Page 15]