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

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.

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 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.

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.


Table of Contents

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 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.

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.

5.3. Required SIP Methods

This section outlines the REQUIRED SIP methods for all RTC-WEB client applications.

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 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. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[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.
[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.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[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.
[I-D.ekr-security-considerations-for-rtc-web] Rescorla, E.K., "Security Considerations for RTC-Web", May 2011.
[I-D.cbran-jennings-rtc-web-nat] Bran, C. and C. Jennings, "RTC-Web Network Address Translation", 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