draft-ietf-mmusic-ice-sip-sdp-21.txt   draft-ietf-mmusic-ice-sip-sdp-22.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 1, 2019 A. Keranen Expires: April 12, 2019 A. Keranen
Ericsson Ericsson
June 30, 2018 October 9, 2018
Session Description Protocol (SDP) Offer/Answer procedures for Session Description Protocol (SDP) Offer/Answer procedures for
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-21 draft-ietf-mmusic-ice-sip-sdp-22
Abstract Abstract
This document describes Session Description Protocol (SDP) Offer/ This document describes Session Description Protocol (SDP) Offer/
Answer procedures for carrying out Interactive Connectivity Answer procedures for carrying out Interactive Connectivity
Establishment (ICE) between the agents. Establishment (ICE) between the agents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2019. This Internet-Draft will expire on April 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 8 3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 8
3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 8 3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 8
3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 9 3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 9
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 9 3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 9
3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 11 3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 11
3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 13 3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 13
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 15 4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 15
4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 18 4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 18
4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 18 4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 18
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 19 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 18
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 19 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 19
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 20 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 20
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 22 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 21
6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23 6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23
6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 23 6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 23
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 23
6.4. Interactions with Preconditions . . . . . . . . . . . . . 24 6.4. Interactions with Preconditions . . . . . . . . . . . . . 24
6.5. Interactions with Third Party Call Control . . . . . . . 24 6.5. Interactions with Third Party Call Control . . . . . . . 24
7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25 7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25 8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25
8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25 8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25
8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 25 8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 25
8.2.2. Interactions with Application Layer Gateways and SIP 26 8.2.2. Interactions with Application Layer Gateways and SIP 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27 9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 34 skipping to change at page 3, line 34
9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31 9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31
9.2. Interactive Connectivity Establishment (ICE) Options 9.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 31 Registry . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 34
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. The remote-candidates Attribute . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 37
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 37
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 38
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 40 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document describes how Interactive Connectivity Establishment This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer (ICE) is used with Session Description Protocol (SDP) offer/answer
[RFC3264]. The ICE specification [ICE-BIS] describes procedures that [RFC3264]. The ICE specification [ICE-BIS] describes procedures that
are common to all usages of ICE and this document gives the are common to all usages of ICE and this document gives the
additional details needed to use ICE with SDP offer/answer. additional details needed to use ICE with SDP offer/answer.
2. Terminology 2. Terminology
skipping to change at page 5, line 50 skipping to change at page 5, line 50
"ice2" ice-options attribute value, the agent assumes that the peer "ice2" ice-options attribute value, the agent assumes that the peer
is compliant to [RFC5245]. is compliant to [RFC5245].
3.2.1.6. Inactive and Disabled Data Streams 3.2.1.6. Inactive and Disabled Data Streams
If an "m=" section is marked as inactive [RFC4566], or has a If an "m=" section is marked as inactive [RFC4566], or has a
bandwidth value of zero [RFC4566], the agent MUST still include ICE bandwidth value of zero [RFC4566], the agent MUST still include ICE
related SDP attributes. related SDP attributes.
If the port value associated with an "m=" section is set to zero If the port value associated with an "m=" section is set to zero
(implying a disabled stream), the agent SHOULD NOT include ICE (implying a disabled stream) as defined in section 8.2 of [RFC3264],
related SDP candidate attributes in that "m=" section, unless an SDP the agent SHOULD NOT include ICE related SDP candidate attributes in
extension specifying otherwise is used. that "m=" section, unless an SDP extension specifying otherwise is
used.
3.2.2. RTP/RTCP Considerations 3.2.2. RTP/RTCP Considerations
If an agent utilizes both RTP and RTCP, the agent MUST include SDP If an agent utilizes both RTP and RTCP, the agent MUST include SDP
candidate attributes for both the RTP and RTCP components in the "m=" candidate attributes for both the RTP and RTCP components in the "m="
section. section.
If an agent uses separate ports for RTP and RTCP, the agent MUST If an agent uses separate ports for RTP and RTCP, the agent MUST
include an SDP rtcp attribute in the "m=" section, as described in include an SDP rtcp attribute in the "m=" section, as described in
[RFC3605]. In the cases where the port number for the RTCP is one [RFC3605]. In the cases where the port number for the RTCP is one
skipping to change at page 9, line 42 skipping to change at page 9, line 46
An agent MAY restart ICE processing for an existing data stream An agent MAY restart ICE processing for an existing data stream
[ICE-BIS]. [ICE-BIS].
The rules governing the ICE restart imply that setting the IP address The rules governing the ICE restart imply that setting the IP address
in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an
ICE restart. Consequently, ICE implementations MUST NOT utilize this ICE restart. Consequently, ICE implementations MUST NOT utilize this
mechanism for call hold, and instead MUST use a=inactive and mechanism for call hold, and instead MUST use a=inactive and
a=sendonly as described in [RFC3264]. a=sendonly as described in [RFC3264].
To restart ICE, an agent MUST change both the ice-pwd and the ice- To restart ICE, an agent MUST change both the ice-pwd and the ice-
ufrag for the data stream in an offer. Note that it is permissible ufrag for the data stream in an offer. However, it is permissible to
to use a session-level attribute in one offer, but to provide the use a session-level attribute in one offer, but to provide the same
same ice-pwd or ice-ufrag as a media-level attribute in a subsequent ice-pwd or ice-ufrag as a media-level attribute in a subsequent
offer. This is not a change in password, just a change in its offer. This MUST NOT be considered as ICE restart.
representation, and does not cause an ICE restart.
An agent sets the rest of the ice related fields in the SDP for this An agent sets the rest of the ice related fields in the SDP for this
data stream as it would in an initial offer of this data stream (see data stream as it would in an initial offer of this data stream (see
Section 3.2.1). Consequently, the set of candidates MAY include Section 3.2.1). Consequently, the set of candidates MAY include
some, none, or all of the previous candidates for that data stream some, none, or all of the previous candidates for that data stream
and MAY include a totally new set of candidates. and MAY include a totally new set of candidates.
3.4.1.1.2. Removing a Data Stream 3.4.1.1.2. Removing a Data Stream
If an agent removes a data stream by setting its port to zero, it If an agent removes a data stream by setting its port to zero, it
skipping to change at page 11, line 19 skipping to change at page 11, line 22
which doesn't even know these pairs are valid, let alone selected. which doesn't even know these pairs are valid, let alone selected.
See Appendix B for elaboration on this race condition. See Appendix B for elaboration on this race condition.
3.4.1.3. Procedures for Lite Implementations 3.4.1.3. Procedures for Lite Implementations
If the ICE state is running, a lite implementation MUST include all If the ICE state is running, a lite implementation MUST include all
of its candidates for each component of each data stream in of its candidates for each component of each data stream in
a=candidate attribute in any subsequent offer. The candidates are a=candidate attribute in any subsequent offer. The candidates are
formed identical to the procedures for initial offers. formed identical to the procedures for initial offers.
A lite implementation MUST NOT add additional host candidates or A lite implementation MUST NOT add additional host candidates in a
change username fragments or passwords in a subsequent offer. subsequent offer. If an agent needs to offer additional candidates,
Otherwise, it MUST restart ICE. it MUST restart ICE. Similarly, the username fragments or passwords
MUST remain the same as used previously. If an agent needs to change
one of these, it MUST restart ICE for that media stream.
If ICE has completed for a data stream and if the agent is If ICE has completed for a data stream and if the agent is
controlled, the default destination for that data stream MUST be set controlled, the default destination for that data stream MUST be set
to the remote candidate of the candidate pair for that component in to the remote candidate of the candidate pair for that component in
the valid list. For a lite implementation, there is always just a the valid list. For a lite implementation, there is always just a
single candidate pair in the valid list for each component of a data single candidate pair in the valid list for each component of a data
stream. Additionally, the agent MUST include a candidate attribute stream. Additionally, the agent MUST include a candidate attribute
for each default destination. for each default destination.
If ICE state is completed and if the agent is controlling (which only If ICE state is completed and if the agent is controlling (which only
skipping to change at page 12, line 43 skipping to change at page 12, line 46
for those checks to complete, and as each completes, redo the for those checks to complete, and as each completes, redo the
processing in this section until there are no losing pairs. processing in this section until there are no losing pairs.
Once there are no losing pairs, the agent can generate the answer. Once there are no losing pairs, the agent can generate the answer.
It MUST set the default destination for media to the candidates in It MUST set the default destination for media to the candidates in
the remote-candidates attribute from the offer (each of which will the remote-candidates attribute from the offer (each of which will
now be the local candidate of a candidate pair in the valid list). now be the local candidate of a candidate pair in the valid list).
It MUST include a candidate attribute in the answer for each It MUST include a candidate attribute in the answer for each
candidate in the remote-candidates attribute in the offer. candidate in the remote-candidates attribute in the offer.
3.4.2.1. Detecting ICE Restart 3.4.2.1. ICE Restart
If the offerer in a subsequent offer requested an ICE restart for a If the offerer in a subsequent offer requested an ICE restart for a
data stream, and if the answerer accepts the offer, the answerer data stream, and if the answerer accepts the offer, the answerer
follows the procedures for generating an initial answer. follows the procedures for generating an initial answer.
For a given data stream, the answerer MAY include the same candidates For a given data stream, the answerer MAY include the same candidates
that were used in the previous ICE session, but it MUST change the that were used in the previous ICE session, but it MUST change the
SDP ice-pwd and ice-ufrag attribute values. SDP ice-pwd and ice-ufrag attribute values.
3.4.2.2. Lite Implementation specific procedures 3.4.2.2. Lite Implementation specific procedures
skipping to change at page 14, line 26 skipping to change at page 14, line 30
list for that data stream. It MUST also terminate any STUN list for that data stream. It MUST also terminate any STUN
transactions in progress for that data stream. transactions in progress for that data stream.
o If the offer/answer exchange added a new data stream, the agent o If the offer/answer exchange added a new data stream, the agent
MUST create a new check list for it (and an empty Valid list to MUST create a new check list for it (and an empty Valid list to
start of course) which in turn triggers the candidate processing start of course) which in turn triggers the candidate processing
procedures [ICE-BIS]. procedures [ICE-BIS].
o If ICE state is running for a given data stream, the agent o If ICE state is running for a given data stream, the agent
recomputes the check list. If a pair on the new check list was recomputes the check list. If a pair on the new check list was
also on the previous check list, and its state was Waiting, In- also on the previous check list, and its state is not Frozen, its
Progress, Succeeded, or Failed, its state is copied over. state is copied over. Otherwise, its state is set to Frozen. If
Otherwise, its state is set to Frozen. If none of the check lists none of the check lists are active (meaning that the pairs in each
are active (meaning that the pairs in each check list are Frozen), check list are Frozen), appropriate procedures in [ICE-BIS] are
appropriate procedures in [ICE-BIS] are performed to move performed to move candidate(s) to the Waiting state to further
candidate(s) to the Waiting state to further continue ICE continue ICE processing.
processing.
o If ICE state is completed and the SDP answer conforms to o If ICE state is completed and the SDP answer conforms to
Section 3.4.2, the agent MUST reman in the ICE completed state. Section 3.4.2, the agent MUST reman in the ICE completed state.
However, if the ICE support is no longer indicated in the SDP answer, However, if the ICE support is no longer indicated in the SDP answer,
the agent MUST fall-back to [RFC3264] procedures and SHOULD NOT drop the agent MUST fall-back to [RFC3264] procedures and SHOULD NOT drop
the dialog because of the missing ICE support or unexpected answer. the dialog because of the missing ICE support or unexpected answer.
Once the agent sends a new offer later on, it MUST perform an ICE Once the agent sends a new offer later on, it MUST perform an ICE
restart. restart.
skipping to change at page 16, line 39 skipping to change at page 16, line 39
This grammar encodes the primary information about a candidate: its This grammar encodes the primary information about a candidate: its
IP address, port and transport protocol, and its properties: the IP address, port and transport protocol, and its properties: the
foundation, component ID, priority, type, and related transport foundation, component ID, priority, type, and related transport
address: address:
<connection-address>: is taken from RFC 4566 [RFC4566]. It is the <connection-address>: is taken from RFC 4566 [RFC4566]. It is the
IP address of the candidate. When parsing this field, an agent IP address of the candidate. When parsing this field, an agent
can differentiate an IPv4 address and an IPv6 address by presence can differentiate an IPv4 address and an IPv6 address by presence
of a colon in its value -- the presence of a colon indicates IPv6. of a colon in its value -- the presence of a colon indicates IPv6.
An agent MUST ignore candidate lines that include candidates with An agent MUST ignore candidate lines that include candidates with
IP address versions that are not supported or recognized. An IP IP address versions that are not supported or recognized.
address SHOULD be used, but an FQDN MAY be used in place of an IP
address. In that case, when receiving an offer or answer
containing an FQDN in an a=candidate attribute, the FQDN is looked
up in the DNS first using an AAAA record (assuming the agent
supports IPv6), and if no result is found or the agent only
supports IPv4, using an A record. The rules from section 6 of
[RFC6724] is followed by fixing the source address to be one from
the candidate pair to be matched against destination addresses
reported by FQDN, in cases where the DNS query returns more than
one IP address.
<port>: is also taken from RFC 4566 [RFC4566]. It is the port of <port>: is also taken from RFC 4566 [RFC4566]. It is the port of
the candidate. the candidate.
<transport>: indicates the transport protocol for the candidate. <transport>: indicates the transport protocol for the candidate.
This specification only defines UDP. However, extensibility is This specification only defines UDP. However, extensibility is
provided to allow for future transport protocols to be used with provided to allow for future transport protocols to be used with
ICE by extending the sub-registry "ICE Transport Protocols" under ICE by extending the sub-registry "ICE Transport Protocols" under
"Interactive Connectivity Establishment (ICE)" registry. "Interactive Connectivity Establishment (ICE)" registry.
skipping to change at page 32, line 27 skipping to change at page 32, line 23
Many thanks to Christer Holmberg for providing text suggestions in Many thanks to Christer Holmberg for providing text suggestions in
Section 3 that aligns with [ICE-BIS] Section 3 that aligns with [ICE-BIS]
Thanks to Thomas Stach for text help, Roman Shpount for suggesting Thanks to Thomas Stach for text help, Roman Shpount for suggesting
RTCP candidate handling and Simon Perreault for advising on IPV6 RTCP candidate handling and Simon Perreault for advising on IPV6
address selection when candidate-address includes FQDN. address selection when candidate-address includes FQDN.
Many thanks to Flemming Andreasen for shepherd review feedback. Many thanks to Flemming Andreasen for shepherd review feedback.
Thanks to following experts for their reviews and constructive Thanks to following experts for their reviews and constructive
feedback: Christer Holmberg, Adam Roach and the MMUSIC WG. feedback: Christer Holmberg, Adam Roach, Peter Saint-Andre and the
MMUSIC WG.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity [ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols", Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-ice-rfc5245bis-00 (work in progress), March draft-ietf-ice-rfc5245bis-00 (work in progress), March
2015. 2015.
skipping to change at page 34, line 31 skipping to change at page 34, line 26
[RFC5768] Rosenberg, J., "Indicating Support for Interactive [RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April
2010, <http://www.rfc-editor.org/info/rfc5768>. 2010, <http://www.rfc-editor.org/info/rfc5768>.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
RFC 6336, April 2010, RFC 6336, April 2010,
<http://www.rfc-editor.org/info/rfc6336>. <http://www.rfc-editor.org/info/rfc6336>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
11.2. Informative References 11.2. Informative References
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<http://www.rfc-editor.org/info/rfc3725>. <http://www.rfc-editor.org/info/rfc3725>.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
 End of changes. 17 change blocks. 
48 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/