Network Working Group L. Yang Internet-Draft G. Mayer Intended status: Standards Track Huawei Expires: December 25, 2010 June 23, 2010 Session Description Protocol (SDP) Extension for a SIP Connection Address Type draft-yang-dispatch-sip-connection-address-type-00 Abstract This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for a SIP connection address type in order to provide a mechanism which allows the transport of a SIP URI within the SDP connection line, for use when the actual IP addresses are not known at offer/ answer time. 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 December 25, 2010. Copyright Notice Copyright (c) 2010 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 Yang & Mayer Expires December 25, 2010 [Page 1] Internet-Draft SIP Connection Address Type June 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . . 4 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . 4 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . . 4 5.2.2. Advanced SDP example . . . . . . . . . . . . . . . . . 5 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Registration of a new "nettype" value . . . . . . . . . . . 6 8.2. Registration of a new "addrtype" value . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. URIs . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yang & Mayer Expires December 25, 2010 [Page 2] Internet-Draft SIP Connection Address Type June 2010 1. Introduction There are different scenarios in which a device needs to establish a media session which is not terminated locally at the establishing device, but at a different entity. Such an entity can for example be a TV set, which shows the video portion of a multimedia phone call, whilst the voice portion is still handled by the local phone, which acts as the controller of the session. Other scenarios require that a device can redirect parts of a session towards a specific media server in the network, e.g. for playing announcements or advertisement to a user. When the controlling device has access to the IP address of the entity to which it wants to redirect the media stream, existing SDP capabilities are sufficient (simply include those IP addresses in the SDP exchange). However, in some scenarios it is not guaranteed that the controlling device has access to this IP address. In some cases the address of the related entity is only known as a URI, e.g. a SIP URI. 2. Conventions Used in this Document 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. Requirements This section presents the general requirements that are specific for the establishment of the collaborative session: REQ-1: a mechanism that allows a device to redirect a local media stream to a dedicated media server within the network (e.g. a streaming server or a TV set), where only a SIP / SIPS URI of the media server is known to the device, i.e. no IP address is known. REQ-2: a mechanism that allows two or more devices to find out whether the remote device supports SIP / SIPS URI addressing of SDP media streams. 4. Overview of Operation The mechanism defined in this memo extends SDP and allows describing the transport of a SIP URI within connection line. New tokens are registered in the "C=" lines to be able to describe a SIP URI. These Yang & Mayer Expires December 25, 2010 [Page 3] Internet-Draft SIP Connection Address Type June 2010 SDP extensions are described in Section 5.2. 4.1. Example In this example, Alice (sip:alice@example1.net) calls Bob (sip:bob@example-remote.net). Alice wants to establish two different media streams: 1. a voice media stream from Alice's device, registered with IP address 192.0.2.5 2. a video media stream from Anna's device, of which Alice only knows the SIP address sip:anna@example2.net In order to achieve this, Alice needs to indicate the following indications in the SDP: m=audio 49170 RTP/AVP 0 8 3 c=IN IP4 192.0.2.5 m=video 9 RTP/AVP 34 c=SIP SIPURI sip:anna@example2.net 5. Protocol Description 5.1. Level of Compliance Implementations of this specification MUST implement the SDP extensions described in Section 5.2. 5.2. Extensions to SDP This section provides the syntax and semantics of the extensions required for providing a description in SDP of audio or video media streams which are established at an entity of which only the SIP address is available. 5.2.1. Connection Data According to SDP [RFC4566], the connection data line in SDP has the following syntax: c= Where indicates the network type, indicates the address type, and the is the connection address, which is dependent on the address type. At the moment, the only network type defined is "IN", which indicates Yang & Mayer Expires December 25, 2010 [Page 4] Internet-Draft SIP Connection Address Type June 2010 Internet network type. The address types "IP4" and "IP6" indicate the type of IP addresses. This memo defines a new network type for describing a SIP-based telecommunication infrastructure. 5.2.2. Advanced SDP example Using the mechanisms described in SDP Capability Negotiation Framework [I-D.ietf-mmusic-sdp-capability-negotiation] and extensions thereof (SDP media capabilities Negotiation[I-D.ietf-mmusic-sdp- media-capabilities] and SDP MiscellaneousCapabilities [I-D.ietf- mmusic-sdp-misc-cap]) it is possible to construct an SDP offer where audio and video media can be offered using either an IP address or a SIP URI. v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 s= t=0 0 c=IN IP4 192.0.2.5 a=creq:ccap-v0 m=audio 49170 RTP/AVP 0 8 3 m=video 49174 RTP/AVP 34 a=ccap:1 SIP SIPS sips:anne@example.com Figure 1 : SDP offer with SIP network type connection data alternative In this example, if the remote side does not support the SIP network type connection data for the video stream, the video stream would automatically be terminated by the originating endpoint at IP address 192.0.2.5. If the terminating endpoint supports the SIP network type connection data, it will respond as follows: v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 s= t=0 0 c=IN IP4 192.0.2.5 a=creq:ccap-v0 m=audio 49170 RTP/AVP 0 8 3 m=video 49174 RTP/AVP 34 c=SIP SIPS sips:anne@example.com Figure 2 : SDP offer with SIP network type connection data accepted Yang & Mayer Expires December 25, 2010 [Page 5] Internet-Draft SIP Connection Address Type June 2010 6. Formal Syntax The following is the formal Augmented Backus-Naur Form (ABNF) [RFC5234] syntax that supports the extensions defined in this specification. The syntax is built above the SDP [RFC4566] grammar. Implementations according to this specification MUST be compliant with this syntax. If the terminating endpoint supports the SIP network type connection data, it will respond as follows: ; extension to the connection field originally specified ; in RFC 4566 connection-field = [%x63 "=" nettype SP addrtype SP connection-address CRLF] ;nettype and addrtype are defined in RFC 4566 connection-address /= URI-address / "-" URI-address = SIP-URI/SIPS-URI Figure 3 : Formal Syntax of the SDP extensions 7. Security Considerations This document provides an extension on top of 4566 [RFC4566]. As such, the security considerations of that document apply. 8. IANA Considerations This document instructs IANA to register a number of SDP tokens according to the following data. NOTE to IANA: please replace "(this RFC)" with the RFC number for this specification when it is available - thanks! 8.1. Registration of a new "nettype" value This memo provides instructions to IANA to register a new "nettype" in the Session Description Protocol Parameters registry [1]. The registration data, according to RFC 4566 [RFC4566] follows. Type SDP Name Reference ---- ------------------ --------- nettype URI [(this RFC)] Yang & Mayer Expires December 25, 2010 [Page 6] Internet-Draft SIP Connection Address Type June 2010 8.2. Registration of a new "addrtype" value This memo provides instructions to IANA to register a new "addrtype" in the Session Description Protocol Parameters registry [1]. The registration data, according to RFC 4566 [RFC4566] follows. Type SDP Name Reference ---- ------------------ --------- addrtype SIPURI [(this RFC)] SIPSURI [(this RFC)] 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 9.2. Informative References [I-D.ietf-mmusic-sdp-capability-negotiation] Andreasen, F., "SDP Capability Negotiation", draft-ietf-mmusic-sdp-capability-negotiation-13 (work in progress), March 2010. [I-D.ietf-mmusic-sdp-media-capabilities] Gilman, R., Even, R., and F. Andreasen, "SDP media capabilities Negotiation", draft-ietf-mmusic-sdp-media-capabilities-09 (work in progress), February 2010. [I-D.ietf-mmusic-sdp-misc-cap] Garcia-Martin, M., Veikkolainen, S., and R. Gilman, "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-misc-cap-00 (work in progress), March 2010. Yang & Mayer Expires December 25, 2010 [Page 7] Internet-Draft SIP Connection Address Type June 2010 [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. Appendix A. URIs [1] Authors' Addresses Lili Yang Huawei Technologies B2, Huawei Industrial Base 518129 China Phone: +86 136 3263 2065 Email: kadyyang@huawei.com Georg Mayer Huawei Technologies Erdbergstrasse 89/20 Wien 1030 Austria Phone: +43 699 1900 5758 Email: georg.mayer@huawei.com Yang & Mayer Expires December 25, 2010 [Page 8]