rtcweb K. Guduru Internet-Draft S.V.University Intended status: Standards Track K. Li Expires: March 1, 2013 Huawei Technologies August 28, 2012 RTCWeb JSEP SIP Mapping draft-guduru-rtcweb-jsep-sip-mapping-00 Abstract This document proposes mapping message representations between RTCWeb Javascript Session Establishment Protocol(JSEP) scheme and SIP messaging scheme. Such a signaling mapping is intended to enable Javascript to use SIP to establish a session between two RTCWeb enabled browsers. 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 March 1, 2013. Copyright Notice Copyright (c) 2012 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 the Trust Legal Provisions and are provided without warranty as Guduru & Li Expires March 1, 2013 [Page 1] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 2.1. Architecture Model . . . . . . . . . . . . . . . . . . . . 3 2.2. Session Management . . . . . . . . . . . . . . . . . . . . 4 3. Media Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Session Management . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Initiate the Session . . . . . . . . . . . . . . . . . 4 3.1.2. Accept the Session . . . . . . . . . . . . . . . . . . 4 3.1.3. Conform the Session . . . . . . . . . . . . . . . . . 5 3.1.4. Terminate the Session . . . . . . . . . . . . . . . . 5 3.1.5. Confirm Session Termination . . . . . . . . . . . . . 5 3.2. Media Management . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Early Media . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. Reliable Early Media . . . . . . . . . . . . . . . . . 6 3.2.3. Updates to the Session . . . . . . . . . . . . . . . . 7 3.3. Queriying capabilities . . . . . . . . . . . . . . . . . . 8 3.3.1. Requesting for Capabilities . . . . . . . . . . . . . 8 3.3.2. Sharing Capabilities . . . . . . . . . . . . . . . . . 9 3.4. Forking requests . . . . . . . . . . . . . . . . . . . . . 9 4. Mapping between SIP Message and JSEP API . . . . . . . . . . . 9 4.1. Map JSEP API to SIP Message . . . . . . . . . . . . . . . 9 4.2. Map SIP Message to JSEP API . . . . . . . . . . . . . . . 10 5. SDP Information Exchange . . . . . . . . . . . . . . . . . . . 11 6. Example Message Flows . . . . . . . . . . . . . . . . . . . . 11 6.1. SIP Session . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Session Update . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Querying Capabilities . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Guduru & Li Expires March 1, 2013 [Page 2] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 1. Introduction In draft [I-D.ietf-rtcweb-jsep], it is mentioned that there are several options for the signalling mechanisms: ROAP (see [I-D.jennings-rtcweb-signaling]), XMPP/Jingle or SIP. This document focuses on SIP and tries to explain how to use JSEP and SIP to exchange session descriptions. 1.1. 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]. 2. Architecture Overview 2.1. Architecture Model Figure Figure 1 represents the overall architecture of realtime peer to peer media communication between two browsers. Here "Browser" is synonymous with "User Agent", and "Web App" is synonymous with "JavaScript". +----------------------+ +---------->| Server |<--------+ | +----------------------+ | | | | SIP | SIP | | v v +-----------+ +-----------+ | Web App | | Web App | +-----------+ +-----------+ ^ ^ | SDP | SDP | | V (JSEP) V (JSEP) +-----------+ +-----------+ | Browser |<=========== Media ============>| Browser | +-----------+ +-----------+ Figure 1: JSEP-SIP Mapping Architecture Guduru & Li Expires March 1, 2013 [Page 3] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 2.2. Session Management The statement machine for session management is same as that described in section 17 of [RFC3261]. Section 3 explains how JS clients could use the SIP messages to manage the session. The detailed descriptions of SIP messages are defined in [RFC3261]. 3. Media Setup 3.1. Session Management 3.1.1. Initiate the Session To initiate a session, the Caller creates an offer and send the offer to Callee by using SIP "INVITE" request with SDP. The JSEP APIs are defined in [webrtc-api] and [I-D.ietf-rtcweb-jsep]. JSEP API: CallerJS->CallerUA: pc = new PeerConnection(); CallerJS->CallerUA: pc.addStream(localStream, null); CallerJS->CallerUA: offer = pc.createOffer(null); SIP message: CallerJS->CalleeJS: SIP INVITE with SDP. After receiving the SIP "INVITE" message, the Callee parses the offer, and applies the supplied offer as the remote description. JSEP API: CalleeJS->CalleeUA: peer.setRemoteDescription("offer",offer); 3.1.2. Accept the Session If the Callee accepts a session, it creates the answer and sends it to Caller by using SIP OK response with SDP. JSEP API: CalleeJS->CalleeUA: peer.addStream(localStream, null); Guduru & Li Expires March 1, 2013 [Page 4] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 CalleeJS->CalleeUA: answer = peer.createAnswer(offer, null); SIP message: CalleeJS->CallerJS: SIP 200 OK with SDP 3.1.3. Conform the Session After receiving the session acceptance, SIP "200 OK" message, the Caller parses the received answer and applies the supplied answer as the remote description to the PeerConnection. JSEP API: CallerJS->CallerUA: pc.setRemoteDescription("answer",answer); Now Caller sends the session confirmation message to Callee by sending the SIP ACK request. SIP message: CallerJS->CalleeJS: SIP ACK 3.1.4. Terminate the Session To terminate a session, the Caller/Callee can close the peer connection by sending the session termination request to the Callee/ Caller by using SIP "BYE" request. SIP message: CallerJS->CalleeJS: SIP BYE. 3.1.5. Confirm Session Termination On receiving the session termination message, the User Agent Server (Caller or Callee that receiving the BYE request) closes the peer connection and responds with a success response to terminate the call with 200 OK response. JSEP API: CalleeJS->CalleeUA: peer.close(). SIP message: CalleeJS->CallerJS: SIP 200 OK. Guduru & Li Expires March 1, 2013 [Page 5] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 After receiving the confirmation for session termination request, the Caller will release the resources in browser through the following JSEP API. JSEP API: CallerJS->CallerUA: pc.close(). 3.2. Media Management 3.2.1. Early Media According to [RFC3261], after receiving the invite, Callee MAY respond with a single or multiple provisional responses (1XX responses other than 100) with or with out SDP. To establish early media between the two peers, these provisional responses must contain SDP. The corresponding JSEP Api is similar to that in Section 3.1.2. SIP message: CalleeJS->CallerJS: SIP 183 "Session Progress" With SDP. 3.2.2. Reliable Early Media 3.2.2.1. Provisional Acknowledgement SIP supports reliability for early media through SIP PRACK message. Based of the specifications mentioned for SIP reliability [RFC3262], Caller can respond with PRACK request for the 183 provisional response. The corresponding JSEP API is similar to that in Section 3.1.2. SIP message: CallerJS->CalleeJS: SIP PRACK. After receiving the SIP UPDATE message, the callee can parse the session information, and apply the supplied offer as the remote description. JSEP API: CalleeJS->CalleeUA: peer.setRemoteDescription("offer", offer); Guduru & Li Expires March 1, 2013 [Page 6] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 3.2.2.2. Accept Provisional Acknowledgement On receiving the Provisional Acknowledgement message from Caller, Callee will accept it by responding with SIP 200 OK response for PRACK. The corresponding JSEP API is similar to that in Section 3.1.3. SIP message: CalleeJS->CallerJS: SIP 200 OK. After receiving the SIP 200 OK message, the caller can parse the session information, and apply the supplied answer as the remote description. JSEP API: CallerJS->CallerUA: peer.setRemoteDescription("answer",answer); 3.2.3. Updates to the Session SIP sessions can be updated to add or remove media or to put one party on hold by the other party. 3.2.3.1. Update session with re-Invite Session updates can be done with re-Invite messages according to [RFC3261]. The processing of re-invites is same as that for the normal invite as explained in Section 3.1.1, Section 3.1.2 and Section 3.1.3. SIP message: CallerJS->CalleeJS: SIP INVITE W/ SDP. CalleeJS->CallerJS: SIP 200 OK W/ SDP. CallerJS->CalleeJS: SIP ACK. 3.2.3.2. Update session with Update request Session updates can also be done with Update requests defined in [RFC3311]. Guduru & Li Expires March 1, 2013 [Page 7] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 3.2.3.2.1. Sending Update Request Session can be refreshed by Caller or Callee by sending the SIP Update request. JSEP API: CallerJS->CallerUA: offer = pc.createOffer(null); SIP message: CallerJS->CaleeJS: SIP UPDATE. 3.2.3.2.2. Accepting the Update Request The User Agent Server that received the Update request, processes it according to rules specified in [RFC3261] and [RFC3311], and sends the SIP 200 OK successful response back to the sender of the request. JSEP API: CalleeJS->CalleeUA: answer = peer.createAnswer(offer, null); SIP message: CalleeJS->CallerJS: SIP 200 OK 3.3. Queriying capabilities Using SIP OPTIONS request Caller can get the capabilities of the Callee, for establishing the session, before the session establishment. In order to support this feature, the browser SHOULD support the other approach for JSEP implementation as specified in 3 of [I-D.ietf-rtcweb-jsep]. 3.3.1. Requesting for Capabilities CallerJS can query for the capabilities of the CalleeJS according to the specifications provided in [RFC3261] by sending SIP OPTIONS request. SIP message: CallerJS->CalleeJS: SIP OPTIONS Guduru & Li Expires March 1, 2013 [Page 8] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 3.3.2. Sharing Capabilities User Agent server, that received the OPTIONS request will share its capabilites with the requester by sending its capabilities in the 200 OK response. JSEP API: CalleeJS->CalleeUA: capablities = getCapabilities(); SIP message: CalleeJS->CallerJS: 200 OK W/ SDP. 3.4. Forking requests According to [I-D.ietf-rtcweb-jsep], JSEP supports forking of forking of requests. The use case for this scenario to happen can be on receiving a SIP redirect request or when the user wants to establish a multiparty session or any other usecase which is out of the scope of this document. This feature can be implemented by sending multiple SIP Invite messages from CallerJS to multiple CalleeJS, following the steps [2.1, 2.2] based on the inputs received. 4. Mapping between SIP Message and JSEP API 4.1. Map JSEP API to SIP Message When CallerJS uses JSEP API to interact with CallerUA, mapping between JSEP API to SIP Message is required, to send the offer to CalleeJS. Figure 2 shows the mapping from JSEP APIs to SIP messages. Guduru & Li Expires March 1, 2013 [Page 9] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 +-------------------------------------+--------------------------+ | JSEP API | SIP Message | +-------------------------------------+--------------------------+ | createOffer(),setLocalDescription() | SIP:Invite | +-------------------------------------+--------------------------+ | createAnswer() | SIP:200 OK | +-------------------------------------+--------------------------+ | setRemoteDescription() | SIP:ACK | +-------------------------------------+--------------------------+ | close() | SIP:BYE | +-------------------------------------+--------------------------+ | getCapabilities() | SIP:200 OK (for options) | +-------------------------------------+--------------------------+ | addStream(),removeStream() | SIP:Re-Invite | +-------------------------------------+---------------------- ---+ | PeerConnectionErrorCallBack() | SIP:4xx, 5xx, 6xx | +-------------------------------------+--------------------------+ Figure 2: Map JSEP API to Jingle Message 4.2. Map SIP Message to JSEP API When CalleeJS recieves SIP Message, it needs to map it to the correspinding JSEP API, to interact with the CalleeUA. Figure 3 shows the mapping from JSEP APIs to SIP messages. +--------------------------+--------------------------------------+ | SIP Message | JSEP API | +--------------------------+--------------------------------------+ | SIP: Invite | setRemoteDescription(),createOffer() | +--------------------------+--------------------------------------+ | SIP: 200 OK | createAnswer() | +--------------------------+--------------------------------------+ | SIP: ACK | setLocalDescription() | +--------------------------+--------------------------------------+ | SIP: BYE | close() | +--------------------------+--------------------------------------+ | SIP: 200 OK (for options)| getCapabilities() | +--------------------------+--------------------------------------+ | SIP: 4xx, 5xx, 6xx | PeerConnectionErrorCallBack() | +--------------------------+--------------------------------------+ Figure 3: Map SIP Message to JSEP API Guduru & Li Expires March 1, 2013 [Page 10] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 5. SDP Information Exchange While using SIP messaging scheme, SDP retrived from the peerconnection (as offer or answer) can be directly mapped to the SDP part of the SIP message. 6. Example Message Flows 6.1. SIP Session Figure 4 represents the basic SIP session flow between two peers, CallerJS uses SIP INVITE method to initiate a session with CalleeJS, this method includes the SDP part in the body of the SIP Message. Then CalleeJS accepts the session using SIP 200 OK message with SDP. Now CallerJS confirms the receipt of session details with SIP ACK request. After the media session, CallerJS uses the SIP BYE request to terminate the session, and CalleeJS acknowledges with SIP 200 OK response. Caller JS Callee JS | | | SIP: INVITE | |-------------------------------------->| | | | SIP: 200 OK | |<--------------------------------------| | | | SIP: ACK | |-------------------------------------->| | | | Media Session | |<=====================================>| | | | SIP: BYE | |-------------------------------------->| | | | SIP: 200 OK | |<--------------------------------------| | | Figure 4: SIP Session Message details go here... Guduru & Li Expires March 1, 2013 [Page 11] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 6.2. Early Media In Figure 5, CallerJS uses SIP INVITE method to initiate a session with CalleeJS, this method includes the SDP part in the body of the SIP Message. Then CalleeJS responds with the SIP 183 session progress provisional response. CallerJS acknowledges this provisional response with SIP PRACK request. Than callerJS confirms the early media session with SIP 200 OK response.SDP session negotiation can heppen in any of these messages according to SIP specification [RFC3261] and SDP offer/answer specification [RFC3262]. Media session can be established with out SIP reliable responses also, if the session negotiations is completed with offer/answer exchange by Invite and 183 response only. Caller JS Callee JS | | | SIP: INVITE | |-------------------------------------->| | | | SIP: 183 Session Progress | |<--------------------------------------| | | | SIP: PRACK | |-------------------------------------->| | | | SIP: 200 OK | |<--------------------------------------| | | | Media Session | |<=====================================>| | | Figure 5: Early Media Message details go here... 6.3. Session Update In Figure 6, CallerJS uses SIP RE-INVITE request with SDP to update session details like adding video to an existing session. CalleeJS accepts that by accepting the media update by SIP 200 OK response with SDP. CallerJS acknowledges this acceptance by SIP ACK request. Guduru & Li Expires March 1, 2013 [Page 12] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 Caller JS Callee JS | | | SIP: RE-INVITE | |-------------------------------------->| | | | SIP: 200 OK | |<--------------------------------------| | | | SIP: ACK | |-------------------------------------->| | | | Media Session | |<=====================================>| | | Figure 6: Session Update Message details go here... In Figure 7, CallerJS uses SIP UPDATE request with SDP to update session details like adding video to an existing session. CalleeJS accepts that by accepting the media updation by SIP 200 OK response with SDP. Caller JS Callee JS | | | SIP: UPDATE | |-------------------------------------->| | | | SIP: 200 OK | |<--------------------------------------| | | | Media Session | |<=====================================>| | | Figure 7: SIP Update Message details go here... 6.4. Querying Capabilities In Figure 8, CallerJS uses SIP OPTIONS request to query the capabilities of the CalleeJS. On receiving this CalleeJS responds with the 200 OK message with all the features supported by it using the getCapabilities method according to SIP [RFC3261]. Guduru & Li Expires March 1, 2013 [Page 13] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 Caller JS Callee JS | | | SIP: OPTIONS | |-------------------------------------->| | | | SIP: 200 OK | |<--------------------------------------| | | Figure 8: Query Capabilities Message details go here... 7. Security Considerations TBD. 8. IANA Considerations This document requires no actions from IANA. 9. Acknowledgements The author would like to thank Kiran Kumar, Bert greevenbosch, Justin Uberti for the reviews and feedbacks. 10. Normative References [I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work in progress), June 2012. [I-D.jennings-rtcweb-signaling] Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/ Answer Protocol (ROAP)", draft-jennings-rtcweb-signaling-01 (work in progress), October 2011. [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. Guduru & Li Expires March 1, 2013 [Page 14] Internet-Draft RTCWeb-JSEP-SIP-Mapping August 2012 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. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [webrtc-api] W3C, "WebRTC 1.0: Real-time Communication Between Browsers", Jul 2012. Authors' Addresses Kiran Kumar Guduru S.V.University D.No: 25-1-996, 6th Lane, Nethaji Nagar Nellore 524004 India Phone: +91-998-5312234 Email: g.kiranreddy4u@gmail.com Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang Shenzhen 518129 P. R. China Phone: +86-755-28971807 Email: likepeng@huawei.com Guduru & Li Expires March 1, 2013 [Page 15]