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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Conventions Used in this Document
3.  Requirements
4.  Overview of Operation
    4.1.  Example
5.  Protocol Description
    5.1.  Level of Compliance
    5.2.  Extensions to SDP
        5.2.1.  Connection Data
        5.2.2.  Advanced SDP example
6.  Formal Syntax
7.  Security Considerations
8.  IANA Considerations
    8.1.  Registration of a new "nettype" value
    8.2.  Registration of a new "addrtype" value
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  URIs
§  Authors' Addresses

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 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=<nettype> <addrtype> <connection-address>

Where <nettype> indicates the network type, <addrtype> indicates the address type, and the <connection-address> is the connection address, which is dependent on the address type.

At the moment, the only network type defined is "IN", which indicates 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

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)]

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

9.2. Informative References

Appendix A.  URIs

[1]  <http://www.iana.org/assignments/sdp-parameters>

Authors' Addresses