Network Working Group C. Jennings Internet-Draft S. Nandakumar Intended status: Standards Track Cisco Expires: April 26, 2012 C. Holmberg Ericsson October 24, 2011 SIP to RTCWeb Offer/Answer Protocol (ROAP) Gateway draft-jennings-rtcweb-signaling-gateway-00 Abstract This document proposes behavior of a RTCWeb signaling gateway for mapping message representations between RTCWeb Offer/Answer Protocol (ROAP) scheme and native SIP messaging scheme. Such a signaling gateway is intended to translate to and from/SIP for enabling use cases between a RTCWeb enabled browser and legacy SIP devices. 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 26, 2012. Copyright Notice Copyright (c) 2011 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 Jennings, et al. Expires April 26, 2012 [Page 1] Internet-Draft SIP2ROAP October 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Mapping to SIP . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. SuccessFull Session Establishment . . . . . . . . . . . . 3 2.2. Add New Media (video) . . . . . . . . . . . . . . . . . . 8 2.3. SuccessFull Session Ending . . . . . . . . . . . . . . . . 11 3. Handling SIP Requests . . . . . . . . . . . . . . . . . . . . 12 4. Handling SIP Responses . . . . . . . . . . . . . . . . . . . . 13 5. Handling Web Messages . . . . . . . . . . . . . . . . . . . . 14 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Jennings, et al. Expires April 26, 2012 [Page 2] Internet-Draft SIP2ROAP October 2011 1. Introduction This specification suggests one possible way to build a RTCWeb Signaling gateway that maps message representations proposed in [ROAP] to native SIP [RFC3261] messages and vice-versa. The specification [ROAP] describes a signaling protocol for RTCWeb to support negotiation of media session using SDP offer/answer [RFC3264] protocol. Such a signaling protocol enables an RTCWeb browser to setup media sessions to another browser or a SIP device. For Browser-to-SIP device use case, the signaling gateway connects to legacy SIP devices and SHALL translate messages between ROAP and SIP native messages schemes. 2. Mapping to SIP Note: The SDP and SIP examples are not correct but illustrate the rough outline of the mechanism. Future version will correct this. The design requires the gateway to be SIP transaction statefull but does not require any storage of longer term state. The information that remains constant over the SIP dialog is stored in session tokens while the information that is needed to from a SIP response is stored in response tokens. The gateway appears as a SIP UA to the sip side. Message on the two sides of the signalling gateway are referred to as the SIP side and web side. The following sub-sections show example message flows with detailed message description of native SIP messages that are mapped from ROAP scheme and the ones that are received as responses by the signaling gateway. CallerUA(callerua@atlanta.example.com) is a RTCWeb browser. CalleeUA(sip:calleeua@sippy.example.com) is assumed to be a SIP- enabled device. It is also assumed that CalleeUA has registered with a SIP proxy server to be able to receive the calls via the proxy. 2.1. SuccessFull Session Establishment In this scenario CallerUA establishes successful media session with CalleeUA, a legacy SIP end-point, with the help of the RTCWeb signaling gateway. Jennings, et al. Expires April 26, 2012 [Page 3] Internet-Draft SIP2ROAP October 2011 participant CallerUA participant CallerJS participant SIPGW participant CalleeUA CallerJS->CallerUA: peer=new PeerConnection(); CallerJS->CallerUA: peer->addStream(); CallerUA->CallerJS: sendSignalingChannel(); CallerJS->SIPGW: {"type":"OFFER", "sdp":"..."} SIPGW->CalleeUA: SIP INVITE note right of CalleeUA: Alert user CalleeUA->CallerUA: ICE Checking CalleeUA->SIPGW: SIP 180 w/SDP SIPGW->CallerJS: {"type":"ANSWER", "more-coming":"TRUE", "sdp":"..."} note right of CallerJS: This SDP has ICE candidates CallerJS->CallerUA: peer->processSignalingMessage(); CallerUA->CallerJS: onstatechange(); note left of CallerUA: Might have one way\nmedia flowing at this point CallerUA->CalleeUA: More ICE checking CalleeUA->CallerUA: ICE Completes CallerUA->CallerJS: onopen(); CalleeUA->SIPGW: SIP 200 SIPGW->CallerJS: {"type":"ANSWER", "sdp":"..."} CallerJS->CallerUA: peer->processSignalingMessage(); CallerUA->CallerJS: onopen(); CalleeUA->CallerUA: Two-way Media note right of CalleeUA: Media plays CallerUA->CallerJS: sendSignalingChannel(); CallerJS->SIPGW: {"type":"OK" } SIPGW->CalleeUA: SIP ACK Message Details Signaling gateway (on behalf of CallerUA) maps ROAP:OFFER (section 5.3.1 of ROAP[ROAP]) to SIP:INVITE and sends it to CalleeUA to start the session. Jennings, et al. Expires April 26, 2012 [Page 4] Internet-Draft SIP2ROAP October 2011 {"type":"OFFER", "offererSessionId":"36707f69b", "seq": 1 "sdp":" v=0 o=callerua 1429 0 IN IP4 client.atlanta.example.com s=Call c=IN IP4 192.0.2.101 t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv" } {INVITE sip:calleeua@sippy.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: CallerUA ;tag=36707f69b To: CalleeUA Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp v=0 o=callerua 1429 0 IN IP4 client.atlanta.example.com s=Call c=IN IP4 192.0.2.101 t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv } SIP:180 from CalleeUA is received at the signaling gateway. Jennings, et al. Expires April 26, 2012 [Page 5] Internet-Draft SIP2ROAP October 2011 {SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: CallerUA ;tag=36707f69b To: CalleeUA ;tag=8321234356 Call-ID:00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 1 INVITE Contact: v=0 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com s=Call c=IN IP4 192.0.2.201 t=0 0 m=audio 16834 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv } This message SHALL be converted to ROAP:Answer (section 5.3.2 of ROAP[ROAP]) with "more-coming" flag set to true as described in the section 5.2.3 of ROAP[ROAP] specification and sent to CallerUA by the signaling gateway. {"type":"ANSWER", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 1, "more-coming": true, "sdp":" v=0 o=callerua 1429 0 IN IP4 client.atlanta.example.com s=Call c=IN IP4 192.0.2.101 t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv" } SIP: OK from CalleeUA is received at the signaling gateway. Jennings, et al. Expires April 26, 2012 [Page 6] Internet-Draft SIP2ROAP October 2011 {SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: CallerUA ;tag=36707f69b To: CalleeUA ;tag=8321234356 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp v=0 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com s=Call c=IN IP4 192.0.2.201 t=0 0 m=audio 16834 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv } This message SHALL be converted to ROAP:Answer(section 5.3.2 of ROAP[ROAP]) and sent to caller by the signaling gateway. This represents a final answer as described in the section 5.2.3 of ROAP[ROAP] {"type":"ANSWER", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 1, "sdp":" v=0 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com s=Call c=IN IP4 192.0.2.201 t=0 0 m=audio 16834 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv" } Signaling gateway (on behalf of CallerUA) maps ROAP:OK (section 5.3.2 of ROAP[ROAP]) to SIP:ACK and sends it to CalleeUA to start the session. This completes call-setup and media streams are established between CallerUA and the CalleeUA. Jennings, et al. Expires April 26, 2012 [Page 7] Internet-Draft SIP2ROAP October 2011 {"type":"OK", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 1 } {ACK sip:calleeua@client.sippy.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: CallerUA ;tag=36707f69b To: CalleeUA ;tag=8321234356 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 1 ACK } 2.2. Add New Media (video) This scenario describes the message exchanges when CalleeUA decides to add video as media to an existing audio-only session participant CallerUA participant CallerJS participant SIPGW participant CalleeUA CalleeUA->CallerUA: Two-way Media (audio only) note right of CalleeUA: Media plays note right of CalleeUA: Callee decides to add video CalleeUA->SIPGW: SIP ReINVITE SIPGW->CallerJS: {"type":"OFFER", "sdp":"..."} CallerJS->CallerUA: peer->processSignalingMessage(); CallerUA->CallerJS: sendSignalingChannel(); CallerJS->SIPGW: {"type":"ANSWER", "sdp":"..."} SIPGW->CalleeUA: SIP 200 CalleeUA->SIPGW: SIP ACK SIPGW->CallerJS: {"type":"OK" } CallerJS->CallerUA: peer->processSignalingMessage(); CallerUA->CallerJS: onaddstream(); CalleeUA->CallerUA: Two-way Media note right of CalleeUA: Media plays with video Jennings, et al. Expires April 26, 2012 [Page 8] Internet-Draft SIP2ROAP October 2011 Message Details On receipt of SIP:INVITE with SDP for video, the signaling gateway maps SIP:INVITE to ROAP:OFFER(section 5.3.1 of ROAP[ROAP]) and sends it to CallerUA indicating the intent. {INVITE sip:callerua@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: CalleeUA ;tag=8321234356 To: CallerUA ;tag=36707f69b Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 2 INVITE Contact: Content-Type: application/sdp v=0 o=callerua 1429 0 IN IP4 client.atlanta.example.com s=SIP Call c=IN IP4 192.0.2.101 t=0 0 m=video 1024 RTP/AVP 97 a=fmtp:97 profile-level-id=42E00C a=sendrecv } CallerUA accepts the new ROAP:OFFER(section 5.3.1 of ROAP[ROAP]) and sends ROAP:ANSWER section 5.3.2 of ROAP[ROAP]). {"type":"OFFER", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 2, "sdp":" v=0 o=callerua 1429 0 IN IP4 client.atlanta.example.com s=Call c=IN IP4 192.0.2.101 t=0 0 m=video 1024 RTP/AVP 97 a=fmtp:97 profile-level-id=42E00C a=sendrecv" } Which results in the follwing answer. Jennings, et al. Expires April 26, 2012 [Page 9] Internet-Draft SIP2ROAP October 2011 {"type":"ANSWER", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 2, "sdp":" v=0 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com s=Call c=IN IP4 192.0.2.201 t=0 0 m=audio 16834 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv" } The signaling gateway maps the ROAP:ANSWER to SIP:200 to be sent to the CalleeUA. { {SIP/2.0 200 OK Via: SIP/2.0/UDP client.sippy.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.201 From: CalleeUA ;tag=8321234356 To: CallerUA ;tag=36707f69b Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 102 INVITE Contact: Content-Type: application/sdp v=0 o=calleeua 2890844527 2890844527 IN IP4 client.sippy.example.com s=SIP Call c=IN IP4 192.0.2.201 t=0 0 m=video 1024 RTP/AVP 97 a=fmtp:97 profile-level-id=42E00C a=sendrecv } CalleeUA accepts the receipt of SIP:200 by sending SIP:ACK. The signaling gateway SIP:ACK to ROAP:OK (section 5.3.2 of ROAP[ROAP]) sends it to CallerUA. This completes adding the new media (video) to the existing session. Jennings, et al. Expires April 26, 2012 [Page 10] Internet-Draft SIP2ROAP October 2011 {ACK sip:callerua@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: calleeua ;tag=8321234356 To: callerua ;tag=36707f69b Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 2 ACK } {"type":"OK", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 2 } 2.3. SuccessFull Session Ending This section capture native SIP message descriptions when the caller decides to end the ongoing session. participant CallerUA participant CallerJS participant SIPGW participant CalleeUA CalleeUA->CallerUA: Two-way Media (audio + video) note right of CalleeUA: Media plays note left of CallerUA: Caller decides to end the session CallerJS->CallerUA: peer->close(); CallerUA->CallerJS: sendSignalingChannel(); CallerJS->SIPGW: {"type":"SHUTDOWN"} SIPGW->CalleeUA: SIP BYE CalleeUA->SIPGW: SIP 200 SIPGW->CallerJS: {"type":"OK"} CallerJS->CallerUA: peer->processSignalingMessage(); Message Details The signaling gateway maps ROAP:SHUTDOWN message from the CallerUA to SIP:BYE and send it to CalleeUA to end the ongoing session. Jennings, et al. Expires April 26, 2012 [Page 11] Internet-Draft SIP2ROAP October 2011 {"type":"SHUTDOWN", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 3 } {BYE sip:callerua@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 From: CallerUA ;tag=36707f69b To: CalleeUA ;tag=8321234356 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 3 BYE } CalleeUA end's the session from it's side by sending SIP:OK. {SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: CallerUA ;tag=36707f69b To: CalleeUA ;tag=8321234356 Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com CSeq: 3 BYE Contact: } This message SHALL be converted to ROAP:OK(section 5.3.2 of ROAP[ROAP]) and sent to caller by the signaling gateway. {"type":"OK", "offererSessionId":"36707f69b", "answererSessionId":"8321234356", "seq": 3 } 3. Handling SIP Requests When the signalling gateway receives a SIP request, the gateway forms the message on the web request side in the following way: 1. The SIP methods INVITE, ACK, BYE, CANCEL are mapped to messageType OFFER, OK, SHUTDOWN, SHUTDOWN respectively 2. The Seq on web side is formed from the numeric portion of CSeq header field value from the SIP side. Jennings, et al. Expires April 26, 2012 [Page 12] Internet-Draft SIP2ROAP October 2011 3. The offererSessionId is formed by a JSON object string that has an call-id attribute containing the SIP call-id header field value and a from-tag attribute containing the SIP from-tag. 4. If there is a SIP to-tag, it is used for the answererSessionId. 5. If there is a SIP body containing SDP, it is copied into the SDP parameter on web side. 6. The setSessionToken is formed by a JSON object string that has contact attribute that contains the SIP contact header field value and an route attribute which is an array that has the values of the SIP route header field values in reverse order. 7. The setResponseToken formed by a JSON object string that has via attribute that is an array containing the SIP via headers field values. The JSON object also includes an attribute that holds the request method. The gateway MAY include any other SIP headers in an attribute named headers which is an array with one header field in each entry. 4. Handling SIP Responses When the signalling gateway receives a SIP response, the gateway forms the message on the web request side in the following way: 1. The SIP responses 180 is mapped to ANSWER with more_coming. A 200 response that contains SDP is mapped to ANSWER. 481 is mapped to NOMATCH. 408 is mapped to TIMEOUT. 486 is mapped to REFUSED. 491 is mapped to CONFLICT. All other SIP 3xx to 6xx responses are mapped to FAILED. 2. The Seq on web side is formed from the numeric portion of CSeq header field value from the SIP side. 3. The offererSessionId is formed by a JSON object string that has an call-id attribute containing the SIP call-id header field value and a from-tag attribute containing the SIP from-tag. 4. The SIP to-tag is used for the answererSessionId. 5. If there is a SIP body containing SDP, it is copied into the SDP parameter on web side. 6. The setSessionToken is formed by a JSON object string that has contact attribute that contains the SIP contact header field value and an route attribute which is an array that has the values of the SIP route header field values. 7. The setResponseToken formed by a JSON object string that has via attribute that is an array containing the SIP via headers field values. The gateway MAY include any other SIP headers in an attribute named headers which is an array with one header field in each entry. Jennings, et al. Expires April 26, 2012 [Page 13] Internet-Draft SIP2ROAP October 2011 5. Handling Web Messages When the signalling gateway receives a WEB message, the gateway forms the message on the SIP side in the following way: 1. The messageType OFFER, ANSWER with more_coming, ANSWER, OK, NOMATCH, TIMEOUT, REFUSED, CONFLICT, FAILED are mapped to INVITE, 180, 200, ACK, 481, 408, 486, 491, 500 respectively. 2. The messageType SHUTDOWN is mapped to a CANCEL if the answererSessionId is empty and to BYE otherwise 3. For SIP responses, The numeric portion of the CSeq is formed by taking the number portion from the Seq field. If the setResponseToken contains a method name, that is used for the method portion of the CSeq otherwise if it does not exist, the request method of the SIP message is used. 4. The Call-ID header field values is formed from the call-id attribute of the offererSessionId. 5. The from-tag is formed from the from-tag attribute of the offererSessionId. 6. If there is a answererSessionId, it is used for the SIP to-tag. 7. If there is a SDP parameter, it is used as a SIP SDP body and the content type of and content length headers are set appropriately. 8. If there is a sessionToken that contains a contact attribute, it is used to form the SIP contact header field value. 9. If there is a sessionToken that contains a route array, it is used to form the SIP route header field values. 10. If there is a responseToken that contains a via array, it is used to form the SIP via header field values. 6. Limitations The following things, if used on the SIP side, will not interoperate: o Redirection via 3xx o UPDATE / PRACK o REFER o SIP to pre RFC 3261 devices that don't support to and from tags. o SUB/NOTify o SIP INVITES that do not contain an SDP offer o SIP extensions to RFC 3261. 7. Security Considerations TBD Jennings, et al. Expires April 26, 2012 [Page 14] Internet-Draft SIP2ROAP October 2011 8. IANA Considerations This document requires no actions from IANA. 9. Acknowledgments 10. References 10.1. Normative References [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [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. [I-D.ietf-rtcweb-use-cases-and-requirements] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft-ietf-rtcweb-use-cases-and-requirements-06 (work in progress), October 2011. [ROAP] Jennings, C. and J. Rosenberg, "RTCWeb Offer/Answer Protocol (ROAP)", draft-jennings-rtcweb-signaling (work in progress), October 2011. Jennings, et al. Expires April 26, 2012 [Page 15] Internet-Draft SIP2ROAP October 2011 Authors' Addresses Cullen Jennings Cisco 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 421-9990 Email: fluffy@cisco.com Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Jennings, et al. Expires April 26, 2012 [Page 16]