One document matched: draft-boucadair-mmusic-altc-00.txt
Network Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Standards Track H. Kaplan
Expires: August 16, 2010 Acme Packet
R. Gilman
Independent
S. Veikkolainen
Nokia
February 12, 2010
Session Description Protocol (SDP) Alternate Connectivity (ALTC)
Attribute
draft-boucadair-mmusic-altc-00.txt
Abstract
This memo proposes a mechanism which allows to carry multiple IP
addresses, of different address families (e.g., IPv4, IPv6), in the
same SDP offer. The proposed attribute solves the backward
compatibility problem which plagued ANAT, due to its syntax.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Boucadair, et al. Expires August 16, 2010 [Page 1]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
This Internet-Draft will expire on August 16, 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 BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Boucadair, et al. Expires August 16, 2010 [Page 2]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 7
4. Alternate Connectivity Attribute . . . . . . . . . . . . . . . 7
4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 9
4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Interaction with ICE . . . . . . . . . . . . . . . . . 10
4.2.3. Interaction with SDP-Cap-Neg . . . . . . . . . . . . . 10
5. The ALTC Option Tag . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Changes Since Last Version . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Boucadair, et al. Expires August 16, 2010 [Page 3]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
1. Introduction
1.1. Overall Context
Due to the IPv4 address exhaustion problem, IPv6 deployment is
becoming an urgent need, along with the need to properly handle IPv6
and IPv4 co-existence. The reality of IPv4-IPv6 co-existence
introduces heterogeneous scenarios with combinations of IPv4 and IPv6
nodes, some of which are capable of supporting both IPv4 and IPv6
dual-stack (DS) and some of which are capable of supporting only IPv4
or only IPv6. In this context, Session Initiation Protocol (SIP)
User Agents (UAs) need to be able to indicate their available IP
capabilities in order to increase the ability to establish successful
SIP sessions, and also to avoid invocation of adaptation functions
such as Application Layer Gateways (ALGs) and IPv4-IPv6
interconnection functions (e.g., NAT64
[I-D.ietf-behave-v6v4-xlate-stateful]), and to avoid using private
IPv4 addresses through consumer NATs or Carrier Grade NATs (CGN).
In the meantime, service providers are investigating scenarios to
upgrade their service offering to be IPv6-capable. The current
strategies involve either offering IPv6 only, for example to mobile
devices, or providing both IPv4 and IPv6 but with private IPv4
addresses which are NAT'ed by CGNs. In the latter case the end
device may be using "normal" IPv4 and IPv6 stacks and interfaces, or
it may tunnel the IPv4 packets though a DS-Lite stack integrated into
the host; in either case the device has both address families
available from a SIP and media perspective.
Regardless of the IPv6 transition strategy being used, it is obvious
that there will be a need for dual-stack SIP devices to communicate
with IPv4-only legacy UAs, and IPv6-only UAs, and other dual-stack
UAs. It may not, for example, be possible for a dual-stack UA to
communicate with an IPv6-only UA unless the dual-stack UA had a means
of providing the IPv6-only UA with its IPv6 local address for media,
while clearly it needs to provide a legacy IPv4-only device its local
IPv4 address. The communication must be possible in a backwards-
compatible fashion, such that IPv4-only SIP devices need not support
the new mechanism to communicate with dual-stack UAs.
The current means by which multiple address families can be
communicated are through ANAT [RFC4091] or ICE [I-D.ietf-mmusic-ice].
ANAT has serious backwards-compatibility problems as described in
[RFC4092], which effectively make it unusable, and it is planned to
be deprecated by the IETF. ICE at least allows interoperability with
legacy devices, by not doing ICE in such cases, but it is a
complicated and processing intensive mechanism, and has seen limited
deployment and implementation in SIP applications. In some
Boucadair, et al. Expires August 16, 2010 [Page 4]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
deployment models, ICE is not usable at all.
1.2. Purpose
This document proposes a new alternative: a backwards-compatible
syntax for indicating multiple media connection addresses and ports
in an SDP offer, which can immediately be selected from and used in
an SDP answer.
The proposed mechanism is independent of the model described in
[I-D.ietf-mmusic-sdp-capability-negotiation] and does not require
implementation of sdp-capabilities-negotiations (a.k.a., sdp-cap-neg)
to function. When sdp-cap-neg is supported, the CCAP attribute
defined in [I-D.garcia-mmusic-sdp-misc-cap] should be used.
It should be noted that "backwards-compatible" in this document
generally refers to working with legacy IPv4-only devices. The
choice has to be made, one way or the other, because to interoperate
with legacy devices requires constructing SDP bodies which they would
understand and support, such that they detect their local address
family in the SDP connection line. It is not possible to support
interworking with both legacy IPv4-only and legacy IPv6-only devices
with the same SDP offer. Clearly, there are far more legacy IPv4-
only devices in existence, and thus those are the ones assumed in
this document. However, the syntax allows for a UA to choose which
address family to be backwards-compatible with, in case it has some
means of determining it.
Furthermore, even for cases where both sides support the same address
family, there should be a means by which the "best" address family
transport is used, based on what the UAs decide. The address family
which is "best" for a particular session cannot always be known a
priori. For example, in some cases the IPv4 transport may be better,
even if both UAs support IPv6.
The proposed solution provides the following benefits:
o Allows a UA to signal more than one IP address (type) in the same
SDP offer/answer;
o Is backwards compatible. No parsing or semantic errors will be
experienced by a legacy UA or intermediary nodes (e.g., Proxy
Servers, Registrar Servers, etc.) which do not understand this new
mechanism;
o Is as lightweight as possible to achieve the goal, while still
allowing and interoperating with nodes which support other similar
or related mechanisms.
Boucadair, et al. Expires August 16, 2010 [Page 5]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
1.3. Scope
This document proposes an alternative scheme, as replacement to the
ANAT procedure, to carry several IP address types in the same SDP
offer/answer while preserving backward compatibility.
While clearly two UAs communicating directly at a SIP layer need to
be able to support the same address family for SIP itself, current
SIP deployments almost always have Proxy Servers or B2BUA's in the
SIP signaling path, which can provide the necessary interworking of
the IP address family at the SIP layer. SIP-layer address family
interworking is out of scope of this document (see
[I-D.boucadair-sipping-ipv6-atypes] for a solution candidate).
Instead, this document focuses on the problem of communicating
*media* address family capabilities in a backwards-compatible
fashion. Since media can go directly between two UAs, without a
priori knowledge by the UAC of which address family the far-end UAS
supports, it has to offer both, in a backwards-compatible fashion.
2. Use Cases
Although the ALTC mechanism defined in this document is meant for
general use, the following use cases were explicitly considered:
o A dual-stack UAC initiating a SIP session without knowing the
address family of the ultimate target UAS.
o A UA receiving a SIP session request with SDP offer and wishes to
avoid using IPv4, or to avoid IPv6.
o An IPv6-only UA wishes to avoid using a NAT64
[I-D.ietf-behave-v6v4-xlate-stateful].
o A SIP UA behind a Dual-Stack Lite CGN
[I-D.ietf-softwire-dual-stack-lite].
o A SIP Service Provider or Enterprise domain of IPv4-only and/or
IPv6-only UA, which provides interworking by invoking IPv4-IPv6
media relays, wishes to avoid invoking such functions and let
media go end-to-end as much as possible.
o A SIP Service Provider or Enterprise domain of a UA, which
communicates with other domains and wishes to either avoid
invoking IPv4-IPv6 interworking or let media go end-to-end as much
as possible.
Boucadair, et al. Expires August 16, 2010 [Page 6]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
o A SIP Service Provider providing transit peering services for SIP
sessions, which may need to modify SDP in order to provide IPv4-
IPv6 interworking, but would prefer to avoid such interworking or
avoid relaying media in general, as much as possible.
o SIP sessions using the new mechanism crossing legacy SDP-aware
middleboxes which may not understand this new mechanism.
3. Overview of the ALTC Mechanism
3.1. Overview
The ALTC mechanism relies solely on the SDP offer/answer mechanism,
with specific syntax to indicate alternative connection addresses.
The basic concept is to use a new SDP attribute "altc", to indicate
the IP addresses for potential alternative connection addresses. The
address which is most likely to get chosen for the session is in the
normal 'c=' line. Typically in current operational networks this
would be an IPv4 address. The "a=altc" lines contain, in preference
order, the alternative addresses offered for this session. This way,
a dual-stack UA might encode its IPv4 address in the "c=" line, while
possibly preferring to use an IPv6 address by indicating this by the
"a=altc" attribute line ordering. One of the "a=altc" lines
duplicates the address contained in the "c=" line, for reasons
explained in Section 3.2). The SDP answerer would indicate its
chosen address, by simply using that address family in the "c=" line
of its response.
An example of an SDP offer using this mechanism is as follows when
IPv4 is considered most likely to be used for the session, but IPv6
is preferred:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::1 45678
a=altc IP4 192.0.2.1 12340
If IPv6 was considered most likely to be used for the session, the
SDP offer would be as follows:
Boucadair, et al. Expires August 16, 2010 [Page 7]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::1 45678
a=altc IP4 192.0.2.1 12340
Since an alternative address is likely to require an alternative TCP/
UDP port number as well, the new "altc" attribute includes both an IP
address and a receive transport port number (or multiple port
numbers). The ALTC mechanism does not itself support offering a
different transport type (i.e., UDP vs. TCP), codec, nor any other
attribute. It is only intended for offering an alternative IP
address and port number.
3.2. Rationale for the Chosen Syntax
The use of an 'a=' attribute line is, according to [RFC4566], the
primary means for extending SDP and tailoring it to particular
applications or media. A compliant SDP parser will ignore any
session description that contains attribute lines it does not
support.
The rationale for encoding the same address and port in the "a=altc"
line as in the "m=" and "c=" lines is to provide detection of legacy
SDP-changing middleboxes. Such systems may change the connection
address and media transport port numbers, but not support this new
mechanism, and thus two UAs supporting this mechanism would try to
connect to the wrong addresses. Therefore, the rules detailed in
this document require the SDP processor to check for matching altc
and connection line addresses and media ports, before choosing one of
the alternatives.
4. Alternate Connectivity Attribute
4.1. ALTC Syntax
The altc attribute adheres to the RFC 4566 "attribute" production.
The ABNF syntax of altc is provided below:
altc-attr = "altc" att-value
att-value = addrtype SP connection-address SP port ["/" integer] ;defined in [RFC4566]
Figure 1: Connectivity Capability Attribute ABNF
Boucadair, et al. Expires August 16, 2010 [Page 8]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
The meaning of the fields are listed hereafter:
o addrtype: the addrtype field as defined in [RFC4566] for
connection data.
o connection-address: a network address as defined in [RFC4566]
corresponding to the address type specified by addrtype.
o port: the port number to be used, as defined in [RFC4566].
Distinct port numbers may be used per IP address type. If the
specified address type does not require a port number, a value
defined for that address type should be used.
The "altc" attribute is only applicable in an SDP offer. The "altc"
attribute is a media-level-only attribute, and MUST NOT appear at the
SDP session level (since it defines a port number, it is inherently
tied to the media level). There MUST NOT be more than one "altc"
attribute per addrtype within each media description. This
restriction is necessary in order that the addrtype of the reply may
be used by the offerer to determine which alternative was accepted.
The <addrtype>'s of the altc MUST correspond to the <nettype> of the
current connection (c=) line.
A media description MUST contain at least two "altc" attributes: the
alternative address and port as well as an address and port which
"duplicates" the address/port information from the current 'c=' and
'm=' lines. Each media level MUST contain at least one such
duplicate altc attribute, of the same IP address family, address, and
transport port number as those in the SDP connection and media lines
of its level. In particular, if a 'c=' line appears within a media
description, the addr-type and connection-address from that 'c=' line
MUST be used in the duplicate "altc" attribute for that media
description. If a 'c=' line appears only at the session level and a
given media description does not have its own connection line, then
the duplicate "altc" attribute for that media description MUST be the
same as the session-level address information.
The "altc" attributes appearing within a media description MUST be
prioritized in order of appearance, with the first altc given highest
priority and the following altc attributes prioritized in decending
order. Given this rule, and the requirement that the address
information provided in the "m=" line and "o=" line must be provided
in an "altc" attribute as well, it is possible that the address in
the "m=" line and "o=" line are not the preferred choice.
If the addrtype of an "altc" attribute is not compatible with the
transport protocol or media format specified in the media
Boucadair, et al. Expires August 16, 2010 [Page 9]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
description, that altc attribute MUST be ignored.
Note that "a=altc" lines describe alternative connection addresses,
NOT addresses for parallel connections. When several altc lines are
present, multiple sessions establishment MUST be avoided. Only one
session is to be maintained with the remote party for the associated
media description.
4.2. Usage and Interaction
4.2.1. Usage
In an SDP offer/answer model, the SDP offer includes "altc"
attributes to indicate alternative connection information (i.e.,
address type, address and port number(s)), including the "duplicate"
connection information already identified in the 'c=' and 'm=' lines.
The SDP answer MUST NOT contain "altc" attributes, as the answer's
'c=' line implicitly and definitively "chooses" the address family
from the offer and includes it in "c=" and "m=" lines of the reply.
Additional, subsequent offers MAY include "altc" attributes again,
and may change the IP address, port numbers, and order of preference;
but they MUST include a duplicate "altc" attribute for the connection
and media lines in that specific subsequent offer. In other words,
every offered SDP media description with an alternative address offer
with an "altc" attribute has at least two of them:
- one duplicating the 'c=' and 'm=' line information for that
media description, and
- one for each of the alternatives,
even though these need not be the same as the original SDP offer.
The purpose of encoding a duplicate "altc" attribute is to allow
receivers of the SDP offer to detect if a legacy SDP-changing middle
box has modified the 'c=' and/or 'm=' line address/port information.
If the SDP answerer does not find a duplicate "altc" attribute value
for which the address and port match exactly those in the 'c=' line
and 'm=' line, the SDP answerer MUST ignore the "altc" attributes and
use the 'c=' and 'm=' offered address/ports for the entire SDP
instead, as if no "altc" attributes were present. The rationale for
this is that many SDP-changing middleboxes will end the media
sessions if they do not detect media flowing through them; if a
middlebox modified the SDP addresses, media MUST be sent using the
modified information.
Note that for RTCP, if applicable for the given media types, each
Boucadair, et al. Expires August 16, 2010 [Page 10]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
side would act as if the chosen "altc" attribute's port number was in
the 'm=' media line. Typically, this would mean RTCP is sent to the
odd +1 of the port number, unless some other attribute determines
otherwise.
4.2.2. Interaction with ICE
Since ICE also includes address and port number information in its
candidate attributes, a potential problem arises: which one wins.
Since ICE also includes specific ICE attributes in the SDP answer,
the problem is easily avoided: if the SDP offerer supports both ALTC
and ICE, it may include both sets of attributes in the same SDP
offer. A legacy ICE-only answerer will simply ignore the ALTC
attributes, and use ICE. An ALTC-only answerer will ignore the ICE
attributes and reply without them. An answerer which supports both
MUST choose one and only one of the mechanisms to use: either ICE or
ALTC (unless the 'm=' or 'c=' lines were changed by a middlebox, in
which case the rules for both ALTC and ICE would make the answerer
revert to basic SDP semantics).
4.2.3. Interaction with SDP-Cap-Neg
The ALTC mechanism is orthogonal to sdp-cap-neg. If the offerer
supports both ALTC and sdp-cap-neg, it may offer both.
A method based on sdp-cap-neg is described in
[I-D.garcia-mmusic-sdp-misc-cap] and may be used to specify different
connectivity for alternative configurations.
5. The ALTC Option Tag
This document defines a new SIP option-tag for use in the "Supported"
SIP header field called "altc". This option-tag is for the purpose
of indicating that a UA supports the ALTC mechanism defined in this
document AND actually has multiple address family addresses
available, in order to improve troubleshooting, and in some cases
provide a hint to other nodes that the UA is capable of both IPv4 and
IPv6 and ALTC.
A UA MUST NOT include this option tag unless it both (1) supports the
ALTC mechanism AND (2) has both an IPv4 and IPv6 address available
for media use. The reason it only includes the "altc" option-tag if
it actually has both addresses, is that having only a single address
family available implies the UA cannot truly perform ALTC in an
offer; it may have the necessary logic to, but it does not have the
addresses to do so. (remember one does not include the "altc"
attribute in SDP unless one has both address families available)
Boucadair, et al. Expires August 16, 2010 [Page 11]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
A UA SHOULD include the ALTC option-tag in a "Supported" SIP header
field in SIP REGISTER, OPTIONS, and INVITE requests and related
responses, if it has both address-family addresses available and
supports the ALTC mechanism. A UA MUST NOT include the ALTC option-
tag in the "Require" or "Proxy-Require" SIP header fields under any
conditions.
6. IANA Considerations
If this document moves forward, it requests a new SDP attribute name
"altc", as defined earlier; and a new SIP option-tag be reserved,
named "altc", for the purposes described earlier.
7. Security Considerations
The security implications for ALTC are effectively the same as they
are for SDP in general.
8. Changes Since Last Version
The following changes have been incorporated since the 00 version of
July 6, 2009:
a. The feature has been renamed from CCAP to ALTC, the SDP
attribute has been renamed "altc", and the SIP option-tag has been
renamed "altc" to describe their meaning as alternative
connections and avoid confusion with Capability Negotiation
(CAPNEG) attributes.
b. The format of the altc attribute has been generalized to
permit use of any defined address type compatible with the
transport protocol and format specified by the media description
in which the altc appears.
c. New co-authors.
9. Acknowledgements
TBC
10. References
Boucadair, et al. Expires August 16, 2010 [Page 12]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session
Description Protocol (SDP) Alternative Network Address
Types (ANAT) Semantics in the Session Initiation Protocol
(SIP)", RFC 4092, June 2005.
[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.
10.2. Informative References
[I-D.boucadair-sipping-ipv6-atypes]
Boucadair, M., Noisette, Y., and A. Allen, "The atypes
media feature tag for Session Initiation Protocol (SIP)",
draft-boucadair-sipping-ipv6-atypes-02 (work in progress),
July 2009.
[I-D.garcia-mmusic-sdp-misc-cap]
Garcia, M., Veikkolainen, S., and R. Gilman,
"Miscellaneous Capabilities Negotiation in the Session
Description Protocol (SDP)",
draft-garcia-mmusic-sdp-misc-cap-01 (work in progress),
July 2009.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
Boucadair, et al. Expires August 16, 2010 [Page 13]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
draft-ietf-behave-v6v4-xlate-stateful-08 (work in
progress), January 2010.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-10 (work in
progress), May 2009.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-stack lite broadband deployments
post IPv4 exhaustion",
draft-ietf-softwire-dual-stack-lite-03 (work in progress),
February 2010.
Authors' Addresses
Mohamed Boucadair
France Telecom
3, Av Francois Chateau
Rennes 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
Email: hkaplan@acmepacket.com
Robert R Gilman
Independent
Email: bob_gilman@comcast.net
URI:
Boucadair, et al. Expires August 16, 2010 [Page 14]
Internet-Draft SDP Alternate Connectivity Attribute February 2010
Simo Veikkolainen
Nokia
Email: Simo.Veikkolainen@nokia.com
URI:
Boucadair, et al. Expires August 16, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 09:45:17 |