One document matched: draft-jennings-rtcweb-signaling-gateway-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-jennings-rtcweb-signaling-gateway-00"
ipr="trust200902">
<front>
<title abbrev="SIP2ROAP">SIP to RTCWeb Offer/Answer Protocol (ROAP)
Gateway</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>snandaku@cisco.com</email>
</address>
</author>
<author fullname="Christer Holmberg" initials="C." surname="Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<region>Jorvas</region>
<code>02420</code>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date day="24" month="October" year="2011" />
<area>RAI</area>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This specification suggests one possible way to build a RTCWeb
Signaling gateway that maps message representations proposed in <xref
target="ROAP"></xref> to native SIP <xref target="RFC3261"> </xref>
messages and vice-versa. The specification <xref target="ROAP"> </xref>
describes a signaling protocol for RTCWeb to support negotiation of
media session using SDP offer/answer <xref target="RFC3264"></xref>
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.</t>
</section>
<section title="Mapping to SIP">
<t><list style="hanging">
<t hangText="Note:">The SDP and SIP examples are not correct but
illustrate the rough outline of the mechanism. Future version will
correct this. </t>
<t hangText=""></t>
</list></t>
<t>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.</t>
<t>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.</t>
<section anchor="sec.successful-session"
title="SuccessFull Session Establishment">
<t>In this scenario CallerUA establishes successful media session with
CalleeUA, a legacy SIP end-point, with the help of the RTCWeb
signaling gateway.</t>
<figure>
<artwork alt="Go Read the TXT version of this draft" src="sse.png"><![CDATA[
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
]]></artwork>
</figure>
<t>Message Details</t>
<t>Signaling gateway (on behalf of CallerUA) maps ROAP:OFFER (section
5.3.1 of ROAP<xref target="ROAP"></xref>) to SIP:INVITE and sends it
to CalleeUA to start the session.</t>
<figure>
<artwork><![CDATA[
{"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"
}
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
<t>SIP:180 from CalleeUA is received at the signaling gateway.</t>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
<t>This message SHALL be converted to ROAP:Answer (section 5.3.2 of
ROAP<xref target="ROAP"></xref>) with "more-coming" flag set to true
as described in the section 5.2.3 of ROAP<xref target="ROAP"></xref>
specification and sent to CallerUA by the signaling gateway.</t>
<figure>
<artwork><![CDATA[
{"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"
}
]]></artwork>
</figure>
<t>SIP: OK from CalleeUA is received at the signaling gateway.</t>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
<t>This message SHALL be converted to ROAP:Answer(section 5.3.2 of
ROAP<xref target="ROAP"></xref>) and sent to caller by the signaling
gateway. This represents a final answer as described in the section
5.2.3 of ROAP<xref target="ROAP"></xref></t>
<figure>
<artwork><![CDATA[
{"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"
}
]]></artwork>
</figure>
<t>Signaling gateway (on behalf of CallerUA) maps ROAP:OK (section
5.3.2 of ROAP<xref target="ROAP"></xref>) 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.</t>
<figure>
<artwork><![CDATA[
{"type":"OK",
"offererSessionId":"36707f69b",
"answererSessionId":"8321234356",
"seq": 1
}
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
</section>
<section anchor="sec.new-media" title="Add New Media (video)">
<t>This scenario describes the message exchanges when CalleeUA decides
to add video as media to an existing audio-only session</t>
<figure>
<artwork alt="Go Read the TXT version of this draft"
src="new-media.png"><![CDATA[
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
]]></artwork>
</figure>
<t>Message Details</t>
<t>On receipt of SIP:INVITE with SDP for video, the signaling gateway
maps SIP:INVITE to ROAP:OFFER(section 5.3.1 of ROAP<xref
target="ROAP"> </xref>) and sends it to CallerUA indicating the
intent.</t>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
<t>CallerUA accepts the new ROAP:OFFER(section 5.3.1 of ROAP<xref
target="ROAP"> </xref>) and sends ROAP:ANSWER section 5.3.2 of
ROAP<xref target="ROAP"></xref>).</t>
<figure>
<artwork><![CDATA[
{"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"
}
]]></artwork>
</figure>
<t>Which results in the follwing answer.</t>
<figure>
<artwork><![CDATA[
{"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"
}
]]></artwork>
</figure>
<t>The signaling gateway maps the ROAP:ANSWER to SIP:200 to be sent to
the CalleeUA.</t>
<figure>
<artwork><![CDATA[
{
{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
}
]]></artwork>
</figure>
<t>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<xref
target="ROAP"></xref>) sends it to CallerUA. This completes adding the
new media (video) to the existing session.</t>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
{"type":"OK",
"offererSessionId":"36707f69b",
"answererSessionId":"8321234356",
"seq": 2
}
]]></artwork>
</figure>
</section>
<section anchor="sec.end-session" title="SuccessFull Session Ending">
<t>This section capture native SIP message descriptions when the
caller decides to end the ongoing session.</t>
<figure>
<artwork alt="Go Read the TXT version of this draft"
src="end-session.png"><![CDATA[
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();
]]></artwork>
</figure>
<t>Message Details</t>
<t>The signaling gateway maps ROAP:SHUTDOWN message from the CallerUA
to SIP:BYE and send it to CalleeUA to end the ongoing session.</t>
<figure>
<artwork><![CDATA[
{"type":"SHUTDOWN",
"offererSessionId":"36707f69b",
"answererSessionId":"8321234356",
"seq": 3
}
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
{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
}
]]></artwork>
</figure>
<t>CalleeUA end's the session from it's side by sending SIP:OK.</t>
<figure>
<artwork><![CDATA[
{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>
}
]]></artwork>
</figure>
<t>This message SHALL be converted to ROAP:OK(section 5.3.2 of
ROAP<xref target="ROAP"></xref>) and sent to caller by the signaling
gateway.</t>
<figure>
<artwork><![CDATA[
{"type":"OK",
"offererSessionId":"36707f69b",
"answererSessionId":"8321234356",
"seq": 3
}
]]></artwork>
</figure>
</section>
</section>
<section title="Handling SIP Requests">
<t>When the signalling gateway receives a SIP request, the gateway forms
the message on the web request side in the following way: <list
style="numbers">
<t>The SIP methods INVITE, ACK, BYE, CANCEL are mapped to
messageType OFFER, OK, SHUTDOWN, SHUTDOWN respectively</t>
<t>The Seq on web side is formed from the numeric portion of CSeq
header field value from the SIP side.</t>
<t>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.</t>
<t>If there is a SIP to-tag, it is used for the
answererSessionId.</t>
<t>If there is a SIP body containing SDP, it is copied into the SDP
parameter on web side.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Handling SIP Responses">
<t>When the signalling gateway receives a SIP response, the gateway
forms the message on the web request side in the following way: <list
style="numbers">
<t>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.</t>
<t>The Seq on web side is formed from the numeric portion of CSeq
header field value from the SIP side.</t>
<t>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.</t>
<t>The SIP to-tag is used for the answererSessionId.</t>
<t>If there is a SIP body containing SDP, it is copied into the SDP
parameter on web side.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Handling Web Messages">
<t>When the signalling gateway receives a WEB message, the gateway forms
the message on the SIP side in the following way: <list style="numbers">
<t>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.</t>
<t>The messageType SHUTDOWN is mapped to a CANCEL if the
answererSessionId is empty and to BYE otherwise</t>
<t>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.</t>
<t>The Call-ID header field values is formed from the call-id
attribute of the offererSessionId.</t>
<t>The from-tag is formed from the from-tag attribute of the
offererSessionId.</t>
<t>If there is a answererSessionId, it is used for the SIP
to-tag.</t>
<t>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.</t>
<t>If there is a sessionToken that contains a contact attribute, it
is used to form the SIP contact header field value.</t>
<t>If there is a sessionToken that contains a route array, it is
used to form the SIP route header field values.</t>
<t>If there is a responseToken that contains a via array, it is used
to form the SIP via header field values.</t>
</list></t>
</section>
<section title="Limitations">
<t>The following things, if used on the SIP side, will not
interoperate:</t>
<t><list style="symbols">
<t>Redirection via 3xx</t>
<t>UPDATE / PRACK</t>
<t>REFER</t>
<t>SIP to pre RFC 3261 devices that don't support to and from
tags.</t>
<t>SUB/NOTify</t>
<t>SIP INVITES that do not contain an SDP offer</t>
<t>SIP extensions to RFC 3261.</t>
</list></t>
</section>
<section anchor="sec-sec" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document requires no actions from IANA.</t>
</section>
<section title="Acknowledgments">
<t><Get your name here></t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol
(SDP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3264" />
<format octets="60854"
target="http://www.rfc-editor.org/rfc/rfc3264.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3261" />
<format octets="647976"
target="http://www.rfc-editor.org/rfc/rfc3261.txt" type="TXT" />
</reference>
<reference anchor="I-D.ietf-rtcweb-use-cases-and-requirements">
<front>
<title>Web Real-Time Communication Use-cases and
Requirements</title>
<author fullname="Christer Holmberg" initials="C" surname="Holmberg">
<organization></organization>
</author>
<author fullname="Stefan Hakansson" initials="S" surname="Hakansson">
<organization></organization>
</author>
<author fullname="Goran Eriksson" initials="G" surname="Eriksson">
<organization></organization>
</author>
<date day="4" month="October" year="2011" />
<abstract>
<t>This 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.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-rtcweb-use-cases-and-requirements-06" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-06.txt"
type="TXT" />
</reference>
<reference anchor="ROAP">
<front>
<title>RTCWeb Offer/Answer Protocol (ROAP)</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<author fullname="Jonathan" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<date day="14" month="October" year="2011" />
<abstract>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-jennings-rtcweb-signaling" />
<format target="http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-jennings-rtcweb-signaling.txt"
type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:07 |