Internet Engineering Task Force SIP WG
Internet Draft G. Camarillo
Ericsson
J. Rosenberg
dynamicsoft
draft-camarillo-mmusic-alt-01.txt
June 17, 2003
Expires: December 2003
The Alternative Semantics for the
Session Description Protocol Grouping Framework
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document defines the alternative (ALT) semantics for the SDP
grouping framework. The ALT semantics allow offering alternative
transport addresses to establish a particular media stream. This is
useful in scenarios that involve IPv4 and IPv6 and/or network address
translators.
G. Camarillo et. al. [Page 1]
Internet Draft SIP June 17, 2003
Table of Contents
1 Introduction ........................................ 3
1.1 Scope ............................................... 3
1.2 Terminology ......................................... 4
2 ALT Semantics ....................................... 4
2.1 Preference .......................................... 4
2.2 Media Stream Establishment Attempts ................. 4
2.2.1 ICE ................................................. 5
2.2.2 Public Addresses .................................... 5
2.3 Backward Compatibility and the "ice" SIP Option
Tag ................................................. 5
2.4 ALT and Media Configurations ........................ 6
3 Example ............................................. 6
4 IANA Considerations ................................. 7
5 Security Considerations ............................. 7
6 Authors' Addresses .................................. 8
7 Normative References ................................ 8
8 Informative References .............................. 9
G. Camarillo et. al. [Page 2]
Internet Draft SIP June 17, 2003
1 Introduction
An SDP [1] session description contains the media parameters to be
used to establish a number of media streams. For a particular media
stream, an SDP session description contains, among other parameters,
the transport addresses and the codec to be used to transfer media.
SDP allows providing a set of codecs per media stream, but only one
transport address.
Being able to provide a set of transport addresses to be tried to
establish a media stream is useful when a system cannot determine its
own transport address as seen from the remote end. This happens when
the end-points support both IPv4 and IPv6 or when there is one or
more NATs (Network Address Translator) between them. In these cases,
although the end-point cannot provide a definitive transport address
to be used for the session at establishment time, it can provide a
set of possible candidates. Those candidates include local IPv4 and
IPv6 addresses and addresses obtained using STUN [7], RSIP [8] and/or
TURN [9].
This document defines the alternative (ALT) semantics for the SDP
grouping framework [2]. The ALT semantics allow expressing
alternative transport addresses for a particular media stream.
1.1 Scope
The ALT semantics are intended to address scenarios where a system
cannot determine its own transport address as seen from the remote
end but can provide a set of possible candidates. When a transport
address that lets the end points communicate to each other is found,
it is supposed to be used for the rest of the session.
Therefore, the set of addresses grouped with ALT is not intended to
be used as a fail-over mechanism (in case the address in use becomes
unreachable). Maintaining some addresses (e.g., addresses obtained
using TURN) throughout the duration of the session would imply to
keep state in the network that would be used only in case of failure.
ALT is not intended to address the pick-one-codec-out-of-N problem
either. In the offer/answer model [3], when an offerer provides a set
of codecs for a media stream, the answerer can use any of them at a
given time. Therefore, the offerer needs to be ready to receive any
of those codecs during the whole session. The offer/answer model does
not have the concept of offering a set of codecs so that the answerer
chooses one and sticks to it for the duration of the session.
New semantics (different than ALT) may be developed in the future to
address the fail-over and the pick-one-codec-out-of-N problems.
G. Camarillo et. al. [Page 3]
Internet Draft SIP June 17, 2003
1.2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant SIP implementations.
2 ALT Semantics
We define a new "semantics" attribute within the SDP grouping
framework [2]: ALT (Alternative).
Media lines grouped using ALT semantics provide alternative transport
addresses for a single logical media stream. The entity receiving a
session description with an ALT group MUST be ready to receive media
over any of the grouped m lines until connectivity is achieved.
2.1 Preference
The entity generating a session description may have an order of
preference for all the alternative transport addresses offered. We
define the q media level attribute to provide this information.
q = "a=q:" qvalue
The q attribute contains a qvalue, as defined in RFC 3261 [5]:
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
The qvalue reflects the desire that the end point has to receive
media on that address, and is assigned as a value from 0 to 1 (1
being most preferred). For example:
a=q:1.0
2.2 Media Stream Establishment Attempts
An entity receiving a set of streams grouped using ALT semantics
cannot assume that it will be possible to successfully use all the
alternative transport addresses offered. Some of the m lines may
G. Camarillo et. al. [Page 4]
Internet Draft SIP June 17, 2003
contain transport addresses that are unreachable for the recipient of
the session description.
Such entity needs to discover which is the transport address with the
highest preference (i.e., highest qvalue) that can be used for the
session. There are two mechanisms to perform this discovery; ICE
(Interactive Connectivity Establishment) [6] and public addresses.
2.2.1 ICE
ICE is intended to be used within the offer/answer model [3]. If the
media lines grouped with ALT in an offer contain "a=stun" attributes,
the answerer MUST use ICE [6] to determine the particular transport
address to be used. This will involve sending STUN requests in
parallel to all the transport addresses, as described in ICE.
2.2.2 Public Addresses
The public addresses mechanism MUST only be used if the generator of
the session description can ensure somehow that the addresses that
appear in the session description are all public IP addresses. For
example, a server could group a multicast IPv4 address and a
multicast IPv6 address using ALT and distribute the session
description using a web page, email or SAP [10].
An entity receiving a session description with an ALT group without
"a=stun" lines SHOULD try to establish the m line with higher
preference whose address understands. How an m line is established
depends on the type of the media stream. Establishing an RTP-based m
line involves sending or waiting for RTP or RTCP packets.
It is RECOMMENDED) that the public address mechanism is only used
with multicast addresses or when the remote party does not support
ICE.
2.3 Backward Compatibility and the "ice" SIP Option Tag
The receiver of a session description with an ALT group is supposed
to establish only one media stream. However, if the entity receiving
such a session description does not understand the ALT semantics or
the grouping framework, it will establish all the streams of the ALT
group. If this entity sends media in parallel over all the streams at
the same time, the resulting session bandwidth will be much higher
than the expected by the creator of the session. If this entity
listens to all the streams (e.g., a session multicast on an IPv4 and
an IPv6 address), the incoming bandwidth as seen by that entity will
be equally high. The ALT semantics MUST NOT be used when this
situation is unacceptable.
G. Camarillo et. al. [Page 5]
Internet Draft SIP June 17, 2003
Note, that if the offer/answer model [3] is being used the offerer
will notice that the answerer did not understand ALT upon reception
of the answer, as described in RFC 3388 [2]. Such an offerer MAY
reissue a new offer with only one m line immediately.
The use of ICE requires further considerations. If an answerer that
does not support ICE receives an m line with a private address and
with an "a=stun" line it will try to send media packets directly to
that address (i.e., it will not use STUN). Those media packets might
arrive to an end-point that happens to use the same private IP
address as the offerer but is in a different realm.
Therefore, the offerer MUST ensure that the answerer supports ICE
before using private IP addresses in a session description. In
scenarios where SIP [5] and the offer/answer model [3] are involved,
the "ice" SIP option tag (defined below) MUST be used to ensure that
the answerer understands the ALT semantics and supports ICE.
Therefore, we define the option tag "ice" for use in the Require and
Supported header fields. A SIP entity that includes the "ice" option
tag in a Supported header field understands the ALT semantics defined
in this document and supports ICE as defined in [6].
2.4 ALT and Media Configurations
The creator of a session description MAY want to use different media
configurations (e.g., audio codec) for different transport addresses
in the same ALT group. The receiver of such a session may find some
of the m lines unacceptable. They may contain codecs that the
answerer does not support or contain any other parameter that makes
them unacceptable. The receiver follows the steps described in
Section 2.2 using only those m lines that were found, in principle,
acceptable.
If the session description is part of an offer/answer exchange, the
answerer will, following normal SIP procedures, set their ports to
zero in the answer.
3 Example
An answerer receiving the offer below will start the ICE procedures
using 192.0.2.2:6886 and 10.0.1.2:22334.
v=0
o=bob 280744730 28977631 IN IP4 host2.example.com
s=
t=0 0
G. Camarillo et. al. [Page 6]
Internet Draft SIP June 17, 2003
a=group:ALT 1 2
m=audio 6886 RTP/AVP 0
c=IN IP4 192.0.2.2
a=mid:1
a=q:1.0
a=stun:user asd8866
m=audio 22334 RTP/AVP 0
c=IN IP4 10.0.1.2
a=mid:2
a=q:1.0
a=stun:user asd8866
4 IANA Considerations
IANA needs to register the following new "semantics" attribute for
the SDP grouping framework [2]:
Semantics Token Reference
------------------- ----- ---------
Alternative ALT [RFCxxxx]
It should be registered in the SDP parameters registry
(http://www.iana.org/assignments/sdp-parameters) under Semantics for
the "group" SDP Attribute.
This document defines a SIP option tag (alt) in Section 2.3. It
should be registered in the SIP parameters registry
(http://www.iana.org/assignments/sip-parameters) under "Option Tags",
with the description below.
A SIP entity that includes the "ice" option tag in a
Supported header field understands the ALT semantics and
supports ICE.
5 Security Considerations
An attacker adding group lines using the ALT semantics to an SDP
session description could make an end-point use only one out of all
the streams offered by the remote end, when the intention of the
remote-end might have been to establish all the streams.
An attacker removing group lines using ALT semantics could make and
end-point establish a higher number of media streams. If the end-
point sends media over all of them, the session bandwidth may
G. Camarillo et. al. [Page 7]
Internet Draft SIP June 17, 2003
increase dramatically.
It is thus STRONGLY RECOMMENDED that integrity protection be applied
to the SDP session descriptions. For session descriptions carried in
SIP [5], S/MIME is the natural choice to provide such end-to-end
integrity protection, as described in RFC 3261. Other applications
MAY use a different form of integrity protection.
6 Authors' Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
electronic mail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Ave
East Hanover, NJ 07936
USA
electronic mail: jdrosen@dynamicsoft.com
7 Normative References
[1] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[2] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne,
"Grouping of media lines in the session description protocol (SDP),"
RFC 3388, Internet Engineering Task Force, Dec. 2002.
[3] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
session description protocol (SDP)," RFC 3264, Internet Engineering
Task Force, June 2002.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[6] J. Rosenberg, "Interactive connectivity establishment (ICE): a
methodology for nettwork address translator (NAT) traversal for the
session initiation protocol (SIP)," internet draft, Internet
G. Camarillo et. al. [Page 8]
Internet Draft SIP June 17, 2003
Engineering Task Force, Feb. 2003. Work in progress.
8 Informative References
[7] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN -
simple traversal of user datagram protocol (UDP) through network
address translators (nats)," RFC 3489, Internet Engineering Task
Force, Mar. 2003.
[8] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi, "Realm
specific IP: protocol specification," RFC 3103, Internet Engineering
Task Force, Oct. 2001.
[9] J. Rosenberg, "Traversal using relay NAT (TURN)," internet draft,
Internet Engineering Task Force, Mar. 2003. Work in progress.
[10] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (c) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
G. Camarillo et. al. [Page 9]
Internet Draft SIP June 17, 2003
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
G. Camarillo et. al. [Page 10]