draft-ietf-mmusic-ice-sip-sdp-25.txt   draft-ietf-mmusic-ice-sip-sdp-26.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: November 13, 2019 A. Keranen Expires: November 18, 2019 A. Keranen
Ericsson Ericsson
May 12, 2019 May 17, 2019
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-25 draft-ietf-mmusic-ice-sip-sdp-26
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 13, 2019. This Internet-Draft will expire on November 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 35 skipping to change at page 2, line 35
3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4 3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4
3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6
3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6
3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6
3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6 3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6
3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7 3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7
3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7 3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7
3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7 3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7
3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8 3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8
3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 8 3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9
3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 8 3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 9
3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 9 3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 9 3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 10
3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 11 3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 12
3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 13 3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 14
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 15 4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . 19
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 18 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 19
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 19 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 20
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 20 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 21 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . 24
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 23 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24
6.4. Interactions with Preconditions . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . 26
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
9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 27 9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 28
9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 27 9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 28
9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 28 9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 29
9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 28 9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 29
9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 29 9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 30
9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 29 9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 30
9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 30 9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 31
9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 30 9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31
9.2. Interactive Connectivity Establishment (ICE) Options 9.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 31 Registry . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 34
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. The remote-candidates Attribute . . . . . . . . . . 36 Appendix B. The remote-candidates Attribute . . . . . . . . . . 38
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 37 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 38 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 [RFC8445] describes procedures that [RFC3264]. The ICE specification [RFC8445] 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 6, line 9 skipping to change at page 6, line 9
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) as defined in section 8.2 of [RFC3264], (implying a disabled stream) as defined in section 8.2 of [RFC3264],
the agent SHOULD NOT include ICE related SDP candidate attributes in the agent SHOULD NOT include ICE related SDP candidate attributes in
that "m=" section, unless an SDP extension specifying otherwise is that "m=" section, unless an SDP extension specifying otherwise is
used. 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, and separate ports are used
candidate attributes for both the RTP and RTCP components in the "m=" for RTP and RTCP, the agent MUST include SDP candidate attributes for
section. both the RTP and RTCP components and SDP rtcp attribute SHOULD be
included in the "m=" section, as described in [RFC3605]
If an agent uses separate ports for RTP and RTCP, the agent MUST In the cases where the port number for the RTCP is one higher than
include an SDP rtcp attribute in the "m=" section, as described in the RTP port and RTCP component address is same as the address of the
[RFC3605]. In the cases where the port number for the RTCP is one RTP component, the SDP rtcp attribute MAY be omitted.
higher than the RTP port and RTCP component address is same as the
address of the RTP component, the SDP rtcp attribute MAY be omitted.
If the agent does not utilize RTCP, it indicates that by including If the agent does not utilize RTCP, it indicates that by including
b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556].
3.2.3. Determining Role 3.2.3. Determining Role
The offerer acts as the Initiating agent. The answerer acts as the The offerer acts as the Initiating agent. The answerer acts as the
Responding agent. The ICE roles (controlling and controlled) are Responding agent. The ICE roles (controlling and controlled) are
determined using the procedures in [RFC8445]. determined using the procedures in [RFC8445].
skipping to change at page 8, line 5 skipping to change at page 7, line 50
3.3. Initial Offer/Answer Exchange 3.3. Initial Offer/Answer Exchange
3.3.1. Sending the Initial Offer 3.3.1. Sending the Initial Offer
When an offerer generates the initial offer, in each "m=" section it When an offerer generates the initial offer, in each "m=" section it
MUST include SDP candidate attributes for each available candidate MUST include SDP candidate attributes for each available candidate
associated with the "m=" section. In addition, the offerer MUST associated with the "m=" section. In addition, the offerer MUST
include an SDP ice-ufrag and an SDP ice-pwd attribute in the offer. include an SDP ice-ufrag and an SDP ice-pwd attribute in the offer.
It is valid for an offer "m=" line to include no SDP candidate
attributes and with default destination corresponding to the IP
address values "0.0.0.0"/"::" and port value of "9". This implies
that offering agent is only going to use peer reflexive candidates or
that additional candidates would be provided in subsequent signaling
messages.
Note: Within the scope of this document, "Initial Offer" refers to Note: Within the scope of this document, "Initial Offer" refers to
the first SDP offer that is sent in order to negotiate usage of the first SDP offer that is sent in order to negotiate usage of
ICE. It might, or might not, be the initial SDP offer of the SDP ICE. It might, or might not, be the initial SDP offer of the SDP
session. session.
Note: The procedures in this document only consider "m=" sections Note: The procedures in this document only consider "m=" sections
associated with data streams where ICE is used. associated with data streams where ICE is used.
3.3.2. Sending the Initial Answer 3.3.2. Sending the Initial Answer
When an answerer receives an initial offer that indicates that the When an answerer receives an initial offer that indicates that the
offerer supports ICE, and if the answerer accepts the offer and the offerer supports ICE, and if the answerer accepts the offer and the
usage of ICE, in each "m=" section within the answer, it MUST include usage of ICE, in each "m=" section within the answer, it MUST include
SDP candidate attributes for each available candidate associated with SDP candidate attributes for each available candidate associated with
the "m=" section. In addition, the answerer MUST include an SDP ice- the "m=" section. In addition, the answerer MUST include an SDP ice-
ufrag and an SDP ice-pwd attribute in the answer. ufrag and an SDP ice-pwd attribute in the answer.
In each "m=" line, the answerer MUST use the same transport protocol
as was used in the offer "m=" line. If none of the candidates in the
"m=" line in the answer use the same transport protocol as indicated
in the offer "m=" line, then, in order to avoid ICE mismatch, the
default destination MUST be set to IP address values "0.0.0.0"/"::"
and port value of "9".
It is also valid for an answer "m=" line to include no SDP candidate
attributes and with default destination corresponding to the IP
address values "0.0.0.0"/"::" and port value of "9". This implies
that answering agent is only going to use peer reflexive candidates
or that additional candidates would be provided in subsequent
signaling messages.
Once the answerer has sent the answer, it can start performing Once the answerer has sent the answer, it can start performing
connectivity checks towards the peer candidates that were provided in connectivity checks towards the peer candidates that were provided in
the offer. the offer.
In certain scenarios when either no candidates were provided in the
offer or all the provided candidates were discarded (say, due to
unsupported address type or FQDN name resolution failure), the
answerer MUST NOT consider this as immediate ICE processing failure
but instead MUST wait for the peer reflexive candidates to arrive to
carryout the connectivity checks or eventually time out on the
connectivity checks (see [draft-holmberg-ice-pac]).
If the offer does not indicate support of ICE, the answerer MUST NOT If the offer does not indicate support of ICE, the answerer MUST NOT
accept the usage of ICE. If the answerer still accepts the offer, accept the usage of ICE. If the answerer still accepts the offer,
the answerer MUST NOT include any ICE related SDP attributes in the the answerer MUST NOT include any ICE related SDP attributes in the
answer. Instead the answerer will generate the answer according to answer. Instead the answerer will generate the answer according to
normal offer/answer procedures [RFC3264]. normal offer/answer procedures [RFC3264].
If the answerer detects a possibility of the ICE mismatch, procedures If the answerer detects a possibility of the ICE mismatch, procedures
described in (Section 3.2.5) are followed. described in (Section 3.2.5) are followed.
3.3.3. Receiving the Initial Answer 3.3.3. Receiving the Initial Answer
When an offerer receives an initial answer that indicates that the When an offerer receives an initial answer that indicates that the
answerer supports ICE, it can start performing connectivity checks answerer supports ICE, it can start performing connectivity checks
towards the peer candidates that were provided in the answer. towards the peer candidates that were provided in the answer.
In certain scenarios when either no candidates were provided in the
answer or all the provided candidates were discarded (say, due to
unsupported address type or FQDN name resolution failure), the
offerer MUST NOT consider this as immediate ICE processing failure
but instead MUST wait for the peer reflexive candidates to arrive to
carryout the connectivity checks or eventually time out on the
connectivity checks (see [draft-holmberg-ice-pac]).
If the answer does not indicate that the answerer supports ICE, or if If the answer does not indicate that the answerer supports ICE, or if
the offerer detects an ICE mismatch in the answer, the offerer MUST the offerer detects an ICE mismatch in the answer, the offerer MUST
terminate the usage of ICE. The subsequent actions taken by the terminate the usage of ICE. The subsequent actions taken by the
offerer are implementation dependent and are out of the scope of this offerer are implementation dependent and are out of the scope of this
specification. specification.
3.3.4. Concluding ICE 3.3.4. Concluding ICE
Once the state of each check list is Completed, and if the agent is Once the state of each check list is Completed, and if the agent is
the controlling agent, it nominates a candidate pair [RFC8445] and the controlling agent, it nominates a candidate pair [RFC8445] and
skipping to change at page 16, line 39 skipping to change at page 17, line 12
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. IP address versions that are not supported or recognized. An IP
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. If a FQDN returns multiple IP
addresses an agent MUST only use one of them throughout the
duration of the ICE session. Since an agent does not know whether
the peer listens to the chosen IP address and port, it is
RECOMMENDED to not use FQDNs that will resolve into multiple IP
addresses.
<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 33, line 48 skipping to change at page 35, line 5
<http://www.rfc-editor.org/info/rfc6336>. <http://www.rfc-editor.org/info/rfc6336>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<http://www.rfc-editor.org/info/rfc8445>. <http://www.rfc-editor.org/info/rfc8445>.
11.2. Informative References 11.2. Informative References
[draft-holmberg-ice-pac]
Holmberg, C. and J. Uberti, "Interactive Connectivity
Establishment Patiently Awaiting Connectivity (ICE PAC)",
draft-holmberg-ice-pac-01 (work in progress), March 2019,
<http://www.ietf.org/internet-drafts/
draft-holmberg-ice-pac-01.txt>.
[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)",
RFC 3960, DOI 10.17487/RFC3960, December 2004, RFC 3960, DOI 10.17487/RFC3960, December 2004,
<http://www.rfc-editor.org/info/rfc3960>. <http://www.rfc-editor.org/info/rfc3960>.
 End of changes. 20 change blocks. 
53 lines changed or deleted 107 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/