Internet DRAFT - draft-boucadair-dispatch-ipv6-atypes
draft-boucadair-dispatch-ipv6-atypes
Network Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Standards Track A. Allen
Expires: December 13, 2013 Blackberry
June 11, 2013
The atypes media feature tag for Session Initiation Protocol (SIP)
draft-boucadair-dispatch-ipv6-atypes-01
Abstract
This specification defines a new media feature tag called atypes.
This new media feature tag indicates the IP address type capabilities
of the UA (User Agent) and can aid the routing process and ease the
invocation of required functions when heterogeneous (i.e., IPv4 and
IPv6) parties are involved in a given SIP session.
This specification solves a problem raised in 3GPP TS 24.229
[TS.24229].
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 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 13, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Boucadair & Allen Expires December 13, 2013 [Page 1]
Internet-Draft The atypes media feature tag June 2013
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.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Justification for atypes . . . . . . . . . . . . . . . . . . 4
3. Relationship of atypes to ICE/ALTC . . . . . . . . . . . . . 5
4. Specification of sip.atypes Media Feature Tag . . . . . . . . 7
4.1. sip.atypes Media Feature Tag . . . . . . . . . . . . . . 7
4.2. Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Session Routing Considerations . . . . . . . . . . . . . 8
5. Examples of atypes tag usages . . . . . . . . . . . . . . . . 8
5.1. IPv4-only UA . . . . . . . . . . . . . . . . . . . . . . 8
5.2. IPv6-only UA . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Dual Stack UA . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Due to IPv4 address exhaustion problem, IPv6 deployment should be
accelerated. In this context and especially from a SIP perspective
[RFC3261], the IPv4-IPv6 co-existence introduces heterogeneous
scenarios with combinations of IPv4 and IPv6 nodes some of which are
Boucadair & Allen Expires December 13, 2013 [Page 2]
Internet-Draft The atypes media feature tag June 2013
capable of supporting both IPv4 and IPv6 (i.e., dual-stack (DS)) and
some of which are capable of supporting only IPv4 or only IPv6.
Additionally, some UAs that are dual-stack capable are unable to use
both interfaces natively at the same time which can mean for example
that if a UA has to use IPv6 for signaling it cannot use IPv4 for
media even though the UA supports an IPv4 stack. This mainly
motivated by restrictions due to available resources such the need to
maintain one PDP (Packet Data Protocol) context in case of mobile
networks.
[RFC6157] provides recommendations to solve this issue including
recommending dual-stack nodes in the core service platform having the
signalling and media path traverse these DS elements. While this is
viable for big service providers it not viable for smaller ones
especially at the earlier stages of IPv6 deployment. Upgrading
existing networks to follow all these recommendations requires a
large investment.
An interim alternative is to use a SIP Application Level Gateway
(ALG) and a IPv4-IPv6 Interworking Function to convert between IPv4
and IPv6 addressing. However an ALG and a IPv4-IPv6 Interworking
Function introduce additional nodes into the signaling and media
paths and can result in the so called "trombone" effect with
signaling and even more importantly media being unnecessarily routed
via an ALG/IPv4-IPv6 Interworking Function in a network located at a
significant distance from both of the UAs involved in the session.
This is particularly significant in mobile networks in roaming
scenarios where potentially media then has be routed via multiple
hops over international links when a roaming user establishes a
session with a user located in the roamed to country. This situation
is potentially unavoidable when an ALG/IPv4-IPv6 Interworking
Function is needed to be inserted in the signaling and the media path
because of incompatible IP versions between UAs that require IP
address translation. It is highly undesirable to redundantly include
ALG/IPv4-IPv6 Interworking nodes in the path when the UAs can
establish sessions without requiring ALG/IPv4-IPv6 Interworking nodes
in the path.
In order to avoid redundant inclusion of ALG/IPv4-IPv6 Interworking
nodes in the path, it is necessary for network nodes to be able to
determine the connectivity types supported by UAs prior to forwarding
session establishment requests. Without such a capability, SIP Proxy
Servers have no way to predict a session failure without a ALG/
IPv4-IPv6 Interworking being included in the path even when ICE
[RFC5245] or ALTC [RFC6947] are also used.
Additionally, when multiple UAs are registered with the same Address
of Record (AoR) it is useful to be able to have a UA indicate a
Boucadair & Allen Expires December 13, 2013 [Page 3]
Internet-Draft The atypes media feature tag June 2013
preference to contact a UA using the mechanism defined in RFC 3841
[RFC3841] that supports the same IP version in order to avoid the
need for ALG/IPv4-IPv6 Interworking node.
This specification also addresses call routing and optimization
mechanisms using the atypes Media Feature Tag to avoid as much as
possible invoking SIP ALGs and IPv4-IPv6 Interworking Function when
establishing a multimedia session between UAs.
2. Justification for atypes
SIP service platforms should be aware of the type of the involved
peers before forwarding session establishment requests. If these
means are not supported, SIP Proxy Servers have no way to predict a
session failure, even if ICE or ALTC procedures are adopted, and also
to optimise the invocation of adaptation functions.
The first alternative to notify the service platform about the type
of the UA is to send SIP REGISTER message which encloses all
available IP addresses. For IPv4-only and IPv6-only UAs, only one
single IP address is carried in SIP REGISTER messages. For DS UAs,
two IP addresses are enclosed. Upon receipt, of this message, the
registrar stores these addresses. Two registration databases may be
maintained, one for IPv4 and another one for IPv6. A second
alternative is to send several REGISTER request using available
connectivity types. In this case, a DS UA sends two REGISTER
messages. The first one is sent using its IPv4 connectivity and the
second one using its IPv6 one. Two databases are maintained by the
conversational service platform. Consequently, upon receipt of an
INVITE, the SIP Proxy Server may question its databases to retrieve
the types of the involved parties. SIP ALG is invoked accordingly.
The drawback of this procedure is that it depends on the behavior of
the terminal. A standardised behavior should be encouraged. To that
aim, a new Media Feature Tag is introduced in this document. More
details are provided hereafter.
According to Section 5.4.4.1 of [TS.24229], if the S-CSCF knows that
the UE supports both versions simultaneously, it forwards the initial
INVITE request to the UE without examining the SDP Offer.
Section 5.4.3.1 of [TS.24229] indicates also if the S-CSCF knows that
the originating UE supports both IPv6 and IPv4 addresses
simultaneously, the S-CSCF will forward the error response to the UE
using the Via header field. However, [TS.24229] does not currently
specify any solution to enable the S-CSCF to get this knowledge.
atypes is intended to be a solution for that problem.
Boucadair & Allen Expires December 13, 2013 [Page 4]
Internet-Draft The atypes media feature tag June 2013
3. Relationship of atypes to ICE/ALTC
ICE [RFC5245] specification deprecates [RFC4091][RFC4092]. Like
ANAT, ICE can be used to enclose both IPv4 and IPv6 information in a
given SDP offer. In the remaining part, ANAT and ICE are used
interchangeably since, from IPv4-IPv6 Interworking perspective, both
provide the same solution. ALTC [RFC6947] is solution that allows to
convey both an IPv4 address and IPv6 address in the same SDP offer.
Both ICE and ALTC make it possible for DS UAs to provide both IPv4
and IPv6 addresses for a single logical media stream. This
singularly helps interworking as, whatever the distant UA version is
(IPv4/IPv6-only or dual-stack), this latter should be able to
understand at least one of the offers. In this way the ICE/ALTC
semantic provides a first approach to interworking problem, when
heterogeneous UAs are involved in the SIP communication. It indeed
improves SIP exchanges, in so far as it allows all sessions arising/
coming from dual-stack UA to lead to successful calls.
This interesting feature needs however to be nuanced, as it
unfortunately does not fit all cases. [RFC4091] already lists some
cases where, depending on the implementation, recipients of an offer
using ANAT might have different behaviours, thus requiring the
introduction of the sdp-anat option-tag. ANAT also requires the UA
to be dual-stack, which means it does not cover the case where UAs
belong to different and restrictive IP version realms. In other
words, the ANAT solution does not help solving scenarios where mono-
stack (i.e., IPv4 or IPv6) UAs are involved. In this latter case,
SIP exchanges can only succeed if intermediary nodes or functions
(Proxy Servers, ALG, Session Border Controllers (SBCs), etc.)
intervene in the signalling path. This intervention, denoted as
IPv4-IPv6 adaptation function in the rest of this document, is
necessary to ensure a successful SIP exchange between these mono-
satck UAs. Unfortunately, in these situations, ANAT/ICE does not
help SIP servers situated all along the signalling path to take the
right decision when IPv4-IPv6 interconnection needs (or should need)
to be tackled.
The atypes Media Feature Tag helps to provide a global answer to the
interconnection problem, when heterogeneous SIP UAs are involved.
Moreover, it aids SIP nodes situated all along the signalling path,
to determine when to invoke the adaptation function helping the
routing of the call.
The atypes Media Feature Tag makes it possible for SIP Proxy Servers
to determine the IP versions supported by the distant and the
originating UA, when they process the initial SIP request. This
means that, the earlier possible in the exchange, a SIP node becomes
Boucadair & Allen Expires December 13, 2013 [Page 5]
Internet-Draft The atypes media feature tag June 2013
aware of the potential interconnection problem due to IP version
incompatibility. This also means that this particular node can
trigger the invocation of the adaptation function, which will modify
the initial SDP offer in order to make this SIP exchange successful.
The atypes Media Feature Tag can therefore aid treatment of all
exchange types intervening between mono-stack (IPv4 or IPv6) or dual-
stack UAs (whether they use ICE or not). Anytime a potential
interconnection problem is suspected using the atypes Media Feature
Tag, the SIP Proxy will be able to drive the adaptation function
invocation and route the SIP exchange accordingly.
The atypes Media Feature Tag can also provide interesting
optimisation characteristics. For instance, a service provider might
force adaptation function like SIP ALGs to be invoked each time the
SIP message leave an IPv4 realm for an IPv6 realm (and vice-versa),
in order to modify the SDP offer accordingly. This kind of
modifications could happen more than once during the SIP signalling
exchanges (and even more than once in a single direction). In the
end, both UAs intervening in the SIP exchange might be of the same
type, thus not requiring any change of the SDP offer. Using the
atypes Media Feature Tag such situation could be avoided, as the SIP
Proxy Server would determine UAs are compatible, thus no modification
should be make to SDP offers, even if Layer 3 information are
modified during the routing of the SIP message.
The atypes Media Feature Tag can also help in the case where
different SIP realms are crossed, where the information from the
atypes Media Feature Tag for the distant UA is not available at the
originating Proxy Server. In this case, the atypes Media Feature Tag
can be included in the SIP request thus enabling the distant SIP
Proxy Server, which has the atypes Media Feature Tag information for
the remote UA, to determine whether to route the SIP request via its
adaptation function.
The atypes Media Feature Tag is not limited to the single IPv4-IPv6
interconnection problem, though this first version of the
specification is dedicated to this usage.
Further values of atypes can be defined in future specifications.
The atypes Media Feature Tag is also compatible with the parallel
usage of ICE or ALTC.
Boucadair & Allen Expires December 13, 2013 [Page 6]
Internet-Draft The atypes media feature tag June 2013
4. Specification of sip.atypes Media Feature Tag
4.1. sip.atypes Media Feature Tag
The 'sip.app-subtype' media feature tag is of type token with a case-
sensitive equality relationship. It indicates whether a
(communications) device supports IPv4 for both signaling and media,
IPv6 for both signaling and media, IPv6 for signaling and IPv4 for
media simultaneously, IPv4 for signaling and IPv6 for media
simultaneously. A plurality of tokens is included for all the
supported combinations. Its values include:
o ipv4: The device supports IPv4.
o ipv6: The device supports IPv6.
Other values of atypes can be defined such as:
o ipv4_via_nat46: When enclosed in a SIP message, a given SIP UA
indicates "here is my IPv4 address, it goes through a translator
so avoid using it if you can utilize my IPv6 address"
o ipv6_via_nat64: When enclosed in a SIP message, a given SIP UA
indicates "here is my IPv6 address, it goes through a translator
so avoid using it if you can utilize my IPv4 address"
o ipv4_via_cgn: When enclosed in a SIP message, a given SIP UA
indicates "here is my IPv4 address, it goes through a CGN device
so avoid using it if you can utilize a public IPv4 or IPv6
address"
4.2. Behavior
When atypes is included in the Contact header field of a REGISTER
request or an INVITE request, a UAC SHOULD include all atypes values
that represent the address type combinations it can currently
support. When included in the Contact header field of a response a
UAS SHOULD include all atypes values that represent the address type
combinations it can currently support.
A UAS that receives an OPTIONS request SHOULD include in the Contact
header field an atypes Media Feature Tag containing all atypes values
that represent the address type combinations it can currently
support.
A given UA MAY restrict its SIP communications to its IPv4-only
interface or IPv6-only ones or MAY use all available ones. The
selected local restriction is conveyed in the atypes Media Feature
Boucadair & Allen Expires December 13, 2013 [Page 7]
Internet-Draft The atypes media feature tag June 2013
Tag. Within this context, an IPv6 interface is judged available only
if the scope of this interface is global and not local to the link.
When included in the Accept-Contact or Reject-Contact header field,
it indicates a desire on the part of a UAC to be connected to a UAS
which can support, or cannot support respectively, the address types
and address type combinations specified.
4.3. Session Routing Considerations
Based on atypes tag value, the Registrar classifies the UA IP address
capabilities for signaling and media.
In order to route calls and to decide the need to invoke a SIP ALG or
to alter SIP messages, which leads to a successful call between
heterogeneous parties, a SIP Proxy Server MAY act as follows:
a. A first alternative is to interrogate the registration database
maintained by the Registrar Server: In this alternative, the SIP
Proxy Server asks the Registrar Server about the type of the
Called and the Caller parties. The SIP Proxy Server decides to
invoke an ALG in case the two involved parties are either
IPv4-only or IPv6-only.
b. The second alternative is to examine the atypes Media Feature Tag
conveyed in the Contact header field of the INVITE request and
the atypes Media Feature Tag values stored by the Registrar
Server for the address type of the Called party. In this
scenario, the SIP Proxy Server routes the call by comparing the
compatibility of the two retrieved atypes values (types of Called
and Caller parties).
5. Examples of atypes tag usages
These sections provide a set of SIP message examples when atypes
media feature tag is used.
5.1. IPv4-only UA
Let consider an IPv4-only UA denoted "HostA". Its IP address is
192.0.2.1. This UA has been provisioned with required contact
information to contact its Registrar (RS). In this example, a FQDN
is provided: registrar.example.com. Means that have been used to
provision the UA are out of scope of this document.
(1) A sends this REGISTER message to its Registrar Server RS:
Boucadair & Allen Expires December 13, 2013 [Page 8]
Internet-Draft The atypes media feature tag June 2013
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5062;branch=z9hG4bK00e31d6ed
Max-Forwards: 70
Content-Length: 0
To: HostA <sip:HostA@example.com>
From: HostA <sip:HostA@example.com>;tag=ed3833bd7363e68
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746364 REGISTER
Contact: HostA <sip:HostA@192.0.2.1:5062>
;atypes="ipv4";expires=900
(2) RS answers to A with a 200 OK message as follows:
SIP/2.0 200 OK
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746365 REGISTER
From: HostA <sip:HostA@example.com>;tag=ed3833bd7363e68
To: HostA <sip:HostA@example.com>;tag=3ab7fe89d998709
Via:SIP/2.0/UDP 192.0.2.1:5062;branch=z9hG4bK00e31d6ed
Content-Length: 0
Contact: HostA <sip:HostA@192.0.2.1:5062>
;atypes="ipv4";expires=900
5.2. IPv6-only UA
Let consider an IPv6-only UA called HostB which IP address is
2001:db8:0:0:1::1. Its attached Registrar Server is identified by
this FQDN: registrar.example.com.
(1) B sends to its Registrar Server the following message:
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP
[2001:db8:0:0:1::1]:5060;branch=z9hG4bK00e31d6ed
Max-Forwards: 70
Content-Length: 0
To: HostB <sip:HostB@example.com>
From: HostB <sip:HostB@example.com>;tag=ed3833bd7363e68
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746364 REGISTER
Contact: HostB <sip:HostB@[2001:db8:0:0:1::1]:5060>
;atypes="ipv6";expires=900
(2) The Registrar Server answers with the following 200 OK message:
Boucadair & Allen Expires December 13, 2013 [Page 9]
Internet-Draft The atypes media feature tag June 2013
SIP/2.0 200 OK
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746365 REGISTER
From: HostB <sip:HostB@example.com>;tag=ed3833bd7363e68
To: HostB <sip:HostB@example.com>;tag=3ab7fe89d998709
Via:SIP/2.0/UDP[2001:db8:0:0:1::1]:5060;branch=z9hG4bK00e31d6ed
Content-Length: 0
Contact: HostB <sip:HostB@[2001:db8:0:0:1::1]:5060>
;atypes="ipv6";expires=900
One IP address MAY be enclosed in the Contact header field of a dual
stack registration message. The type of the contact address MAY be
distinct from the value of atypes. For instance:
o an IPv4 address may be enclosed in the Contact header field even
if the assigned atypes value is equal to "ipv6",
o or only one IP address may be carried in the Contact header field
even if the atypes value is set to "ipv6,ipv4".
The IP address in the Contact header field MAY be used by
intermediary proxies when contacting the UA.
5.3. Dual Stack UA
Let consider a dual-stack UA (DS) which IP addresses are
2001:db8:0:0:1::1 and 192.0.2.2 which does not support IPv4 and IPv6
simultaneously. The FQDN of the Register Server is
registrar.example.com.
(1) DS sends a REGISTER message to its Registrar Server as follows:
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK00e31d6ed
Max-Forwards: 70
Content-Length: 0
To: DS <sip:DS@example.com>
From: DS <sip:DS@example.com>;tag=ed3833bd7363e68
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746364 REGISTER
Contact: DS <sip:DS@192.0.2.2:5060>
;atypes="ipv4,ipv6";expires=900
(2) The Registrar Server answers with a 200 OK message as shown
below:
Boucadair & Allen Expires December 13, 2013 [Page 10]
Internet-Draft The atypes media feature tag June 2013
SIP/2.0 200 OK
Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com
CSeq: 1830746365 REGISTER
From: DS <sip: DS@example.com>;tag=ed3833bd7363e68
To: DS <sip:DS@example.com>;tag=3ab7fe89d998709
Via:SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK00e31d6ed
Content-Length: 0
Contact: DS <sip:DS@192.0.2.2:5060>
;atypes="ipv4,ipv6";expires=900
6. IANA Considerations
This specification adds a new media feature tag to the SIP Media
Feature Tag Registration Tree defined in RFC 3840 [RFC3840].
Media feature tag name: sip.atypes
ASN.1 Identifier: TBD
Summary of the media feature indicated by this tag: The sip.atypes
media feature tag indicates whether a communications device supports
IPv4 for both signaling and media, IPv6 for both signaling and media,
IPv6 for signaling and IPv4 for media simultaneously, IPv4 for
signaling and IPv6 for media simultaneously. A plurality of tokens
is included for all the supported combinations.
Values appropriate for use with this feature tag: Token with an
equality relationship.
Typical values include:
ipv4: The device can support IPv4 addresses for both signaling and
media.
ipv6: The device can support IPv6 addresses for both signaling and
media.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA.
Examples of typical use: Optimally routing a session and ensuring
compatibility between IP versions to successfully establish sessions.
Related standards or documents: RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]].
Boucadair & Allen Expires December 13, 2013 [Page 11]
Internet-Draft The atypes media feature tag June 2013
Security Considerations: Security considerations for this media
feature tag are discussed in Section 7 of RFC XXXX . [[Note to IANA:
Please replace XXXX with the RFC number of this specification.]]
7. Security Considerations
SIP-related security considerations are discussed in [RFC3261].
When present in a SIP request or response, this media feature tag may
be used to determine whether a session is routed via a ALG/IPv4-IPv6
Interworking Function in order to successfully establish a session.
If the values of the atypes Media Feature Tags are modified by an
intermediary then it is possible that a session would fail to be
established if the modified values caused the network proxies to not
insert a ALG/IPv4-IPv6 Interworking Function when they are needed.
However if the contact address itself is also modified this could
also prevent a session being established. Integrity protection for
the Contact header field SHOULD be provided.
8. References
8.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.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
8.2. Informative References
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[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.
Boucadair & Allen Expires December 13, 2013 [Page 12]
Internet-Draft The atypes media feature tag June 2013
[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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)", RFC
6157, April 2011.
[RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "The Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute", RFC 6947, May
2013.
[TS.24229]
3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", March 2013.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Andrew Allen
Blackberry
USA
Email: aallen@blackberry.com
Boucadair & Allen Expires December 13, 2013 [Page 13]
