One document matched: draft-cbran-rtcweb-negotiation-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cbran-rtcweb-negotiation-00"
ipr="noDerivativesTrust200902">
<front>
<title abbrev="Abbreviated-Title">RTC-Web Negotiation and
Signaling</title>
<author fullname="Cary Bran" initials="C." surname="Bran">
<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 206 256-3502</phone>
<email>cbran@cisco.com</email>
</address>
</author>
<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>
<date day="4" month="July" year="2011" />
<abstract>
<t>This document outlines the negotiation and signaling protocols for
RTC-Web client application implementation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An integral part of the success and adoption of the Real-Time
Communications Web (RTC-WEB) will be the interoperability between
RTC-Web applications running on different browsers or different versions
of a browser. As browser features evolve, new codecs are deployed, and
more advanced features are added, it is critical to have a negotiation
framework between browsers to facilitate evolution of real time
communications on the web. It is also important for negotiation in a
backwards compatible way with legacy VoIP equipment. This specification
proposes negotiation and signaling requirements for enabling broad
interoperability capabilities for RTC-Web client applications.</t>
<t>The negotiation and signaling requirements fit into a series of
specifications have been created to address RTC-Web codec, NAT
traversal, security, data transmission and use case requirements. More
information on the RTC-Web can be found here:</t>
<t>[TODO put links to supporting drafts here]</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Introduction">
<t>This proposal supports an architecture where the negotiations happen
directly between two browsers (or other RTC-Web client applications) or
a model where the browser routes the negotiation via a third server that
helps facilitate the negotiation. In the first model where
communications are direct, it is assumed that ICE has already been used
to set up a communication channel between the browsers that can be used
for negotiation.</t>
<t>While SIP is used in this proposal, it is a restricted subset of the
SIP functionally for initiating and setting up RTP streams and
rendezvous services for these messages.</t>
</section>
<section title="Negotiation Requirements">
<t>This section details the secure channel negotiation requirements for
RTC-Web client applications. The requirements below originate from the
RTC-Web NAT draft <xref
target="I-D.cbran-jennings-rtc-web-nat"></xref>.</t>
<section title="ICE">
<t>It is plausible that many RTC-WEB client applications, such as web
browsers will be deployed behind a NAT. To set up secure data plane
sessions, and address the security requirements identified in <xref
target="Security"></xref> all RTC-WEB client application
implementations are REQUIRED to natively expose an implementation of
either ICE <xref target="RFC5245"></xref> or ICE-Lite (Section 2.7 of
<xref target="RFC5245"></xref>). Implicit to implementing ICE, all
RTC-WEB client applications are REQUIRED to implement Simple Traversal
of User Datagram Protocol (UDP) Through Network Address Translators
(NATs) (STUN) <xref target="RFC3489"></xref> and Traversal Using
Relays around NAT (TURN) <xref target="RFC5766"></xref>.</t>
<t>Echoing from he RTC-Web NAT draft <xref
target="I-D.cbran-jennings-rtc-web-nat"></xref>, ICE is REQUIRED be
implemented and available natively from the RTC-Web client
application. What this means via example is; if the RTC-Web client
application happens to be a web browser, the web browser MUST
implement ICE such that adheres to the RTC-Web NAT draft <xref
target="I-D.cbran-jennings-rtc-web-nat"></xref>.</t>
</section>
</section>
<section title="Signaling Protocol Requirements">
<t>This section covers the signaling protocol to be used by RTC-WEB
applications. To ensure interoperability not just between RTC-WEB
applications, but with legacy PBX phone systems as well, a small subset
of SIP will be REQUIRED for all RTC-WEB client application
implementations. In addition to the subset of SIP specification <xref
target="RFC3261"></xref>, RTC-WEB client application implementations
will be REQUIRED to support DNS resolutions as specified in <xref
target="RFC3263"></xref> and the offer/answer model with SDP as
specified in <xref target="RFC3264"></xref>.</t>
<t>Because the browsers only need to use a small subset of SIP, the
specification assumes that a majority of SIP implementations will
interoperate with the browsers.</t>
<section title="Client Application SIP Requirements">
<t>This section focuses on the subset of SIP functionality that will
exist within all RTC-WEB client applications. The following User Agent
Client (UAC) subset of the SIP specification <xref
target="RFC3261"></xref> is REQUIRED.</t>
<t><list style="symbols">
<t>General User Agent Behavior - [Section 8]</t>
<t>Registration - [Section 10]</t>
<t>Client Transaction - [Section 17.1]</t>
<t>Canceling a Request - [Section 9.1]</t>
<t>Terminating a Session - [Section 15.1], [Section 15.1.1]</t>
<t>3.XX Redirect Responses - [Section 8.1.3.4]</t>
<t>TLS - [Section 26.3.1]</t>
<t>Outbound Proxy</t>
</list></t>
</section>
<section title="Client Application Optional SIP Support">
<t>In the SIP specification <xref target="RFC3261"></xref>, the SIP
features listed below are required for all UAC implementations.
RTC-WEB client applications are not a fully featured SIP UAC and will
only be implementing a subset of the SIP specification. Thusly, unlike
SIP UACs, the following list of SIP features is to be considered
OPTIONAL for RTC-WEB client application implementations.</t>
<t><list style="symbols">
<t>INVITEs without an offer</t>
<t>re-INVITEs – [Section 14.1]</t>
<t>forking – [Section 19.3]</t>
<t>S/MIME – [Section 23]</t>
<t>SIPS URI Scheme – [Section 26.2.2]</t>
</list></t>
</section>
<section title="Required SIP Methods">
<t>This section outlines the REQUIRED SIP methods for all RTC-WEB
client applications.</t>
<t><list style="symbols">
<t>INVITE – <xref target="RFC3261"></xref> - Section 13</t>
<t>REGISTER – <xref target="RFC3261"></xref> - Section
10</t>
<t>ACK - <xref target="RFC3261"></xref> - Section 13.2</t>
<t>CANCEL - <xref target="RFC3261"></xref> - Section 13.2</t>
<t>BYE - <xref target="RFC3261"></xref> - Section 13.2</t>
<t>UPDATE – <xref target="RFC3311"></xref></t>
</list></t>
</section>
<section title="Multipart SIP Message Requirements">
<t>For handling SIP messages RTC-WEB client applications are required
to implement the multipart MIME handling scheme as specified in <xref
target="RFC5621"></xref>.</t>
</section>
<section title="Identity Requirements">
<t>Identity, for the purposes of this section, is defined as a SIP
URI. There are two areas concerning SIP identity this specification
will address.</t>
<t>The first area covers validation of the message originator. To
securely validate a the identity of a SIP message originator, all
RTC-WEB client applications are REQUIRED to implement the mechanism
specified in <xref target="RFC4474"></xref>.</t>
<t>To support cases were the identify of a caller/callee may change,
such as when a call is parked and transferred from the original callee
to another party, all RTC-WEB client applications are REQUIRED to
implement the identity mechanism specified in <xref
target="RFC4916"></xref>. <xref target="RFC3261"></xref>implicitly
REQUIRES the implementation of the UPDATE method as specified in <xref
target="RFC3311"></xref></t>
</section>
<section title="Network Address Traversal">
<t>RTC-WEB client applications MUST support Network Address Translator
(NAT) traversal. This section will address SIP-related areas to
support NAT traversal.</t>
<t>As called for in the negotiation requirements; RTC-WEB client
applications will implement STUN. To support client-managed
connections, STUN-based keep-alives as specified in <xref
target="RFC5626"></xref> are REQUIRED.</t>
<t>When SIP is used with UDP, responses to requests are returned to
the source address the request came from, and to the port written into
the topmost Via header field value of the request. This behavior is
not desirable when the RTC-WEB client application is behind a Network
Address Translator (NAT). To address UDP traversal problem the "rport"
extension as specified in <xref target="RFC3581"></xref> is
REQUIRED.</t>
</section>
</section>
<section title="Legacy VoIP Interoperability">
<t>The RTC-Web negotiation requirements specify a discrete subset of the
SIP specification. The discrete subset was chosen to implicitly enable
broad interoperability between RTC-Web client applications and legacy
VoIP systems.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Because there are a number of security issues, considerations and
requirements for RTC-WEB client applications there is a draft that
specifically addresses the RTC-WEB application security considerations.
This draft defers it's security considerations and requirements to the
security considerations for RTC-Web draft <xref
target="I-D.ekr-security-considerations-for-rtc-web"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>[TODO - Are there any yet for this area?]</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4916.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3581.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5621.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml'?>
<reference anchor="I-D.ekr-security-considerations-for-rtc-web">
<front>
<title abbrev="RTC-Web Security">Security Considerations for
RTC-Web</title>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
<organization>RTFM, Inc.</organization>
<address>
<postal>
<street>2064 Edgewood Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>
<phone>+1 650 678 2350</phone>
<email>ekr@rtfm.com</email>
</address>
</author>
<date day="30" month="May" year="2011" />
<area>RAI</area>
<workgroup>RTC-Web</workgroup>
<abstract>
<t>The Real-Time Communications on the Web (RTC-Web) working group
is tasked with standardizing protocols for real-time
communications between Web browsers. The two major use cases for
RTC-Web technology are real-time audio and/or video calls and
direct data transfer. Unlike most conventional real-time systems
(e.g., SIP-based soft phones) RTC-Web communications are directly
controlled by some Web server, which poses new security
challenges. For instance, a Web browser might expose a JavaScript
API which allows a server to place a video call. Unrestricted
access to such an API would allow any site which a user visited to
"bug" a user's computer, capturing any activity which passed in
front of their camera. This document defines the RTC-Web threat
model and defines an architecture which provides security within
that threat model.</t>
</abstract>
<note title="Legal">
<t>THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE
PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING
TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
</reference>
<reference anchor="I-D.cbran-jennings-rtc-web-nat">
<front>
<title abbrev="RTC WEB NAT">RTC-Web Network Address
Translation</title>
<author fullname="Cary Bran" initials="C." surname="Bran">
<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 206 256-3502</phone>
<email>cbran@cisco.com</email>
</address>
</author>
<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>
<date month="July" year="2011" />
<area>RAI</area>
<workgroup>RTCWEB</workgroup>
<keyword>NAT</keyword>
<abstract>
<t>This document outlines the network address translation (NAT)
mechanisms and requirements for RTC-Web client applications.</t>
</abstract>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:21:12 |