One document matched: draft-yang-dispatch-sip-connection-address-type-00.txt
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=<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
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] <http://www.iana.org/assignments/sdp-parameters>
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:13:20 |