SIP to RTCWeb Offer/Answer Protocol (ROAP)
GatewayCisco170 West Tasman DriveSan JoseCA95134USA+1 408 421-9990fluffy@cisco.comCisco170 West Tasman DriveSan JoseCA95134USAsnandaku@cisco.comEricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.com
RAI
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.This specification suggests one possible way to build a RTCWeb
Signaling gateway that maps message representations proposed in to native SIP
messages and vice-versa. The specification
describes a signaling protocol for RTCWeb to support negotiation of
media session using SDP offer/answer
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.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.In this scenario CallerUA establishes successful media session with
CalleeUA, a legacy SIP end-point, with the help of the RTCWeb
signaling gateway.Message DetailsSignaling gateway (on behalf of CallerUA) maps ROAP:OFFER (section
5.3.1 of ROAP) to SIP:INVITE and sends it
to CalleeUA to start the session.SIP:180 from CalleeUA is received at the signaling gateway.This message SHALL be converted to ROAP:Answer (section 5.3.2 of
ROAP) with "more-coming" flag set to true
as described in the section 5.2.3 of ROAP
specification and sent to CallerUA by the signaling gateway.SIP: OK from CalleeUA is received at the signaling gateway.This message SHALL be converted to ROAP:Answer(section 5.3.2 of
ROAP) and sent to caller by the signaling
gateway. This represents a final answer as described in the section
5.2.3 of ROAPSignaling gateway (on behalf of CallerUA) maps ROAP:OK (section
5.3.2 of 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.This scenario describes the message exchanges when CalleeUA decides
to add video as media to an existing audio-only sessionMessage DetailsOn receipt of SIP:INVITE with SDP for video, the signaling gateway
maps SIP:INVITE to ROAP:OFFER(section 5.3.1 of ROAP) and sends it to CallerUA indicating the
intent.CallerUA accepts the new ROAP:OFFER(section 5.3.1 of ROAP) and sends ROAP:ANSWER section 5.3.2 of
ROAP).Which results in the follwing answer.The signaling gateway maps the ROAP:ANSWER to SIP:200 to be sent to
the CalleeUA.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) sends it to CallerUA. This completes adding the
new media (video) to the existing session.This section capture native SIP message descriptions when the
caller decides to end the ongoing session.Message DetailsThe signaling gateway maps ROAP:SHUTDOWN message from the CallerUA
to SIP:BYE and send it to CalleeUA to end the ongoing session.CalleeUA end's the session from it's side by sending SIP:OK.This message SHALL be converted to ROAP:OK(section 5.3.2 of
ROAP) and sent to caller by the signaling
gateway.When the signalling gateway receives a SIP request, the gateway forms
the message on the web request side in the following way: The SIP methods INVITE, ACK, BYE, CANCEL are mapped to
messageType OFFER, OK, SHUTDOWN, SHUTDOWN respectivelyThe Seq on web side is formed from the numeric portion of CSeq
header field value from the SIP side.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.If there is a SIP to-tag, it is used for the
answererSessionId.If there is a SIP body containing SDP, it is copied into the SDP
parameter on web side.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.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.When the signalling gateway receives a SIP response, the gateway
forms the message on the web request side in the following way: 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.The Seq on web side is formed from the numeric portion of CSeq
header field value from the SIP side.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.The SIP to-tag is used for the answererSessionId.If there is a SIP body containing SDP, it is copied into the SDP
parameter on web side.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.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.When the signalling gateway receives a WEB message, the gateway forms
the message on the SIP side in the following way: 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.The messageType SHUTDOWN is mapped to a CANCEL if the
answererSessionId is empty and to BYE otherwiseFor 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.The Call-ID header field values is formed from the call-id
attribute of the offererSessionId.The from-tag is formed from the from-tag attribute of the
offererSessionId.If there is a answererSessionId, it is used for the SIP
to-tag.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.If there is a sessionToken that contains a contact attribute, it
is used to form the SIP contact header field value.If there is a sessionToken that contains a route array, it is
used to form the SIP route header field values.If there is a responseToken that contains a via array, it is used
to form the SIP via header field values.The following things, if used on the SIP side, will not
interoperate:Redirection via 3xxUPDATE / PRACKREFERSIP to pre RFC 3261 devices that don't support to and from
tags.SUB/NOTifySIP INVITES that do not contain an SDP offerSIP extensions to RFC 3261.TBDThis document requires no actions from IANA.<Get your name here>An Offer/Answer Model with Session Description Protocol
(SDP)Key words for use in RFCs to Indicate
Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordSIP: Session Initiation ProtocolWeb Real-Time Communication Use-cases and
RequirementsThis document describes web based real-time communication
use-cases. Based on the use-cases, the document also derives
requirements related to the browser, and the API used by web
applications to request and control media stream services provided
by the browser.RTCWeb Offer/Answer Protocol (ROAP)This document describes an protocol used to negotiate media
between browsers or other compatible devices. This protocol
provides the state machinery needed to implement the offer/answer
model (RFC 3264), and defines the semantics and necessary
attributes of messages that must be exchanged. The protocol uses
an abstract transport in that it does not actually define how
these messages are exchanged. Rather, such exchanges are handled
through web-based transports like HTTP or WebSockets. The protocol
focuses solely on media negotiation and does not handle call
control, call processing, or other functions.