Network Working Group C. Jennings
Internet-Draft S. Nandakumar
Intended status: Standards Track Cisco
Expires: April 27, 2012 C. Holmberg
Ericsson
October 25, 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.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

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 27, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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.

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.

 {"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 <sip:callerua@atlanta.example.com>;tag=36707f69b
To: CalleeUA <sip:calleeua@sippy.example.com>
Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:callerua@client.atlanta.example.com;transport=udp>
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.

{SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
From: CallerUA <sip:callerua@atlanta.example.com>;tag=36707f69b
To: CalleeUA <sip:calleeua@sippy.example.com>;tag=8321234356
Call-ID:00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:calleeua@client.sippy.example.com;transport=udp>

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.

{SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
From: CallerUA <sip:callerua@atlanta.example.com>;tag=36707f69b
To: CalleeUA <sip:calleeua@sippy.example.com>;tag=8321234356
Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:calleeua@client.sippy.example.com;transport=udp>
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.

 {"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 <sip:callerua@atlanta.example.com>;tag=36707f69b
To: CalleeUA <sip:calleeua@sippy.example.com>;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

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 <sip:calleeua@sippy.example.com>;tag=8321234356
To: CallerUA <sip:callrua@atlanta.example.com>;tag=36707f69b
Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:calleeua@client.sippy.example.com;transport=udp>
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.

 {"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 <sip:calleeua@sippy.example.com>;tag=8321234356
To: CallerUA <sip:calleeua@sippy.example.com>;tag=36707f69b
Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com
CSeq: 102 INVITE
Contact: <sip:callerua@client.atlanta.example.com;transport=udp>
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.

{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 <sip:calleeua@sippy.example.com>;tag=8321234356
To: callerua <sip:callerua@atlanta.example.com>;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.

 {"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 <sip:callerua@atlanta.example.com>;tag=36707f69b
To: CalleeUA <sip:calleeua@sippy.example.com>;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 <sip:callerua@atlanta.example.com>;tag=36707f69b
To: CalleeUA <sip:calleeua@sippy.example.com>;tag=8321234356
Call-ID: 00000000-00000003-2331a5b0-2aa0cdf5@atlanta.example.com
CSeq: 3 BYE
Contact: <sip:calleeua@client.sippy.example.com;transport=udp>
}

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.
  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.

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:

7. Security Considerations

TBD

8. IANA Considerations

This document requires no actions from IANA.

9. Acknowledgments

<Get your name here>

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", Internet-Draft draft-ietf-rtcweb-use-cases-and-requirements-06, October 2011.
[ROAP] Jennings, C. and J. Rosenberg, "RTCWeb Offer/Answer Protocol (ROAP)", Internet-Draft draft-jennings-rtcweb-signaling, 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