One document matched: draft-cbran-rtcweb-negotiation-00.txt
Network Working Group C. Bran
Internet-Draft C. Jennings
Intended status: Standards Track Cisco
Expires: January 5, 2012 July 4, 2011
RTC-Web Negotiation and Signaling
draft-cbran-rtcweb-negotiation-00
Abstract
This document outlines the negotiation and signaling protocols for
RTC-Web client application implementation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 January 5, 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.
Bran & Jennings Expires January 5, 2012 [Page 1]
Internet-Draft Abbreviated-Title July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Negotiation Requirements . . . . . . . . . . . . . . . . . . . 3
4.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Signaling Protocol Requirements . . . . . . . . . . . . . . . . 4
5.1. Client Application SIP Requirements . . . . . . . . . . . . 4
5.2. Client Application Optional SIP Support . . . . . . . . . . 5
5.3. Required SIP Methods . . . . . . . . . . . . . . . . . . . 5
5.4. Multipart SIP Message Requirements . . . . . . . . . . . . 6
5.5. Identity Requirements . . . . . . . . . . . . . . . . . . . 6
5.6. Network Address Traversal . . . . . . . . . . . . . . . . . 6
6. Legacy VoIP Interoperability . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Bran & Jennings Expires January 5, 2012 [Page 2]
Internet-Draft Abbreviated-Title July 2011
1. Introduction
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.
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:
[TODO put links to supporting drafts here]
2. Terminology
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 RFC 2119 [RFC2119].
3. Introduction
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.
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.
4. Negotiation Requirements
This section details the secure channel negotiation requirements for
RTC-Web client applications. The requirements below originate from
Bran & Jennings Expires January 5, 2012 [Page 3]
Internet-Draft Abbreviated-Title July 2011
the RTC-Web NAT draft [I-D.cbran-jennings-rtc-web-nat].
4.1. ICE
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
Section 8 all RTC-WEB client application implementations are REQUIRED
to natively expose an implementation of either ICE [RFC5245] or ICE-
Lite (Section 2.7 of [RFC5245]). 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) [RFC3489] and Traversal Using Relays around
NAT (TURN) [RFC5766].
Echoing from he RTC-Web NAT draft [I-D.cbran-jennings-rtc-web-nat],
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
[I-D.cbran-jennings-rtc-web-nat].
5. Signaling Protocol Requirements
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
[RFC3261], RTC-WEB client application implementations will be
REQUIRED to support DNS resolutions as specified in [RFC3263] and the
offer/answer model with SDP as specified in [RFC3264].
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.
5.1. Client Application SIP Requirements
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 [RFC3261] is
REQUIRED.
o General User Agent Behavior - [Section 8]
Bran & Jennings Expires January 5, 2012 [Page 4]
Internet-Draft Abbreviated-Title July 2011
o Registration - [Section 10]
o Client Transaction - [Section 17.1]
o Canceling a Request - [Section 9.1]
o Terminating a Session - [Section 15.1], [Section 15.1.1]
o 3.XX Redirect Responses - [Section 8.1.3.4]
o TLS - [Section 26.3.1]
o Outbound Proxy
5.2. Client Application Optional SIP Support
In the SIP specification [RFC3261], 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.
o INVITEs without an offer
o re-INVITEs - [Section 14.1]
o forking - [Section 19.3]
o S/MIME - [Section 23]
o SIPS URI Scheme - [Section 26.2.2]
5.3. Required SIP Methods
This section outlines the REQUIRED SIP methods for all RTC-WEB client
applications.
o INVITE - [RFC3261] - Section 13
o REGISTER - [RFC3261] - Section 10
o ACK - [RFC3261] - Section 13.2
o CANCEL - [RFC3261] - Section 13.2
o BYE - [RFC3261] - Section 13.2
Bran & Jennings Expires January 5, 2012 [Page 5]
Internet-Draft Abbreviated-Title July 2011
o UPDATE - [RFC3311]
5.4. Multipart SIP Message Requirements
For handling SIP messages RTC-WEB client applications are required to
implement the multipart MIME handling scheme as specified in
[RFC5621].
5.5. Identity Requirements
Identity, for the purposes of this section, is defined as a SIP URI.
There are two areas concerning SIP identity this specification will
address.
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 [RFC4474].
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 [RFC4916].
[RFC3261]implicitly REQUIRES the implementation of the UPDATE method
as specified in [RFC3311]
5.6. Network Address Traversal
RTC-WEB client applications MUST support Network Address Translator
(NAT) traversal. This section will address SIP-related areas to
support NAT traversal.
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 [RFC5626] are
REQUIRED.
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 [RFC3581] is REQUIRED.
6. Legacy VoIP Interoperability
The RTC-Web negotiation requirements specify a discrete subset of the
Bran & Jennings Expires January 5, 2012 [Page 6]
Internet-Draft Abbreviated-Title July 2011
SIP specification. The discrete subset was chosen to implicitly
enable broad interoperability between RTC-Web client applications and
legacy VoIP systems.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
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
[I-D.ekr-security-considerations-for-rtc-web].
9. Acknowledgements
[TODO - Are there any yet for this area?]
10. Normative References
[I-D.cbran-jennings-rtc-web-nat]
Bran, C. and C. Jennings, "RTC-Web Network Address
Translation", July 2011.
[I-D.ekr-security-considerations-for-rtc-web]
Rescorla, E., "Security Considerations for RTC-Web",
May 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
Bran & Jennings Expires January 5, 2012 [Page 7]
Internet-Draft Abbreviated-Title July 2011
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric Response
Routing", RFC 3581, August 2003.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
Bran & Jennings Expires January 5, 2012 [Page 8]
Internet-Draft Abbreviated-Title July 2011
Authors' Addresses
Cary Bran
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 206 256-3502
Email: cbran@cisco.com
Cullen Jennings
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Bran & Jennings Expires January 5, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 08:41:57 |