| Network Working Group | C. Bran |
| Internet-Draft | C. Jennings |
| Intended status: Standards Track | Cisco |
| Expires: January 05, 2012 | July 04, 2011 |
RTC-Web Negotiation and Signaling
draft-cbran-rtcweb-negotiation-00
This document outlines the negotiation and signaling protocols for RTC-Web client application implementation.
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 January 05, 2012.
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.
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.
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]
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].
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.
This section details the secure channel negotiation requirements for RTC-Web client applications. The requirements below originate from the RTC-Web NAT draft [I-D.cbran-jennings-rtc-web-nat].
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].
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.
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.
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.
This section outlines the REQUIRED SIP methods for all RTC-WEB client applications.
For handling SIP messages RTC-WEB client applications are required to implement the multipart MIME handling scheme as specified in [RFC5621].
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]
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.
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.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
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].
[TODO - Are there any yet for this area?]