draft-ietf-asap-sip-auto-peer-03.txt   draft-ietf-asap-sip-auto-peer-04.txt 
ASAP K. Inamdar ASAP K. Inamdar
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track S. Narayanan Intended status: Standards Track S. Narayanan
Expires: 27 April 2022 C. Jennings Expires: 27 April 2022 C. Jennings
Cisco Systems Cisco Systems
24 October 2021 24 October 2021
Automatic Peering for SIP Trunks Automatic Peering for SIP Trunks
draft-ietf-asap-sip-auto-peer-03 draft-ietf-asap-sip-auto-peer-04
Abstract Abstract
This draft specifies a configuration workflow to enable enterprise This draft specifies a configuration workflow to enable enterprise
Session Initiation Protocol (SIP) networks to solicit the capability Session Initiation Protocol (SIP) networks to solicit the capability
set of a SIP service provider network. The capability set can set of a SIP service provider network. The capability set can
subsequently be used to configure features and services on the subsequently be used to configure features and services on the
enterprise edge element, such as a Session Border Controller (SBC), enterprise edge element, such as a Session Border Controller (SBC),
to ensure smooth peering between enterprise and service provider to ensure smooth peering between enterprise and service provider
networks. networks.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.5. Identifying the Request Target . . . . . . . . . . . . . 11 4.5. Identifying the Request Target . . . . . . . . . . . . . 11
4.6. Generating the response . . . . . . . . . . . . . . . . . 12 4.6. Generating the response . . . . . . . . . . . . . . . . . 12
5. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 13 5. State Deltas . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Encoding the Service Provider Capability Set . . . . . . . . 13 6. Encoding the Service Provider Capability Set . . . . . . . . 13
7. Data Model for Capability Set . . . . . . . . . . . . . . . . 13 7. Data Model for Capability Set . . . . . . . . . . . . . . . . 13
7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13
7.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 22 7.3. Node Definitions . . . . . . . . . . . . . . . . . . . . 22
7.4. Extending the Capability Set . . . . . . . . . . . . . . 32 7.4. Extending the Capability Set . . . . . . . . . . . . . . 32
8. Processing the Capability Set Response . . . . . . . . . . . 33 8. Processing the Capability Set Response . . . . . . . . . . . 33
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. JSON Capability Set Document . . . . . . . . . . . . . . 34 9.1. JSON Capability Set Document . . . . . . . . . . . . . . 33
9.2. Example Exchange . . . . . . . . . . . . . . . . . . . . 36 9.2. Example Exchange . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
12. Normative References . . . . . . . . . . . . . . . . . . . . 37 12. Normative References . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The deployment of a Session Initiation Protocol [RFC3261] (SIP)-based The deployment of a Session Initiation Protocol [RFC3261] (SIP)-based
infrastructure in enterprise and service provider communication infrastructure in enterprise and service provider communication
networks is increasing at a rapid pace. Consequently, direct IP networks is increasing at a rapid pace. Consequently, direct IP
peering between enterprise and service provider networks is quickly peering between enterprise and service provider networks is quickly
replacing traditional methods of interconnection between enterprise replacing traditional methods of interconnection between enterprise
and service provider networks. Currently published standards provide and service provider networks. Currently published standards provide
skipping to change at page 8, line 9 skipping to change at page 8, line 9
characteristics of the intermediary SIP service provider network is characteristics of the intermediary SIP service provider network is
out of the scope of this document; however, one method could be for out of the scope of this document; however, one method could be for
the terminating SIP service provider to obtain the characteristics of the terminating SIP service provider to obtain the characteristics of
the intermediary SIP service provider by leveraging the YANG model the intermediary SIP service provider by leveraging the YANG model
introduced in this document. introduced in this document.
3. Conventions and Terminology 3. Conventions and Terminology
The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14 this document are to be interpreted as described in [BCP-14]
(https://www.rfc-editor.org/refs/ref-bcp14.txt)
4. HTTP Transport 4. HTTP Transport
This section describes the use of HTTPS as a transport protocol for This section describes the use of HTTPS as a transport protocol for
the peering workflow. This workflow is based on HTTP version 1.1, the peering workflow. This workflow is based on HTTP version 1.1,
and as such is compatible with any future version of HTTP that is and as such is compatible with any future version of HTTP that is
backward compatible with HTTP 1.1. backward compatible with HTTP 1.1.
4.1. HTTP Methods 4.1. HTTP Methods
skipping to change at page 8, line 32 skipping to change at page 8, line 31
and its corresponding response(s) to request for and subsequently and its corresponding response(s) to request for and subsequently
obtain the service provider capability set document. obtain the service provider capability set document.
4.2. Integrity and Confidentiality 4.2. Integrity and Confidentiality
Peering requests and responses are defined over HTTPS. However, due Peering requests and responses are defined over HTTPS. However, due
to the sensitive nature of information transmitted between client and to the sensitive nature of information transmitted between client and
server, it is required to secure HTTP using Transport Layer Security server, it is required to secure HTTP using Transport Layer Security
[RFC5246]. The enterprise edge element and capability server MUST be [RFC5246]. The enterprise edge element and capability server MUST be
compliant with [RFC7235]. The enterprise edge element and capability compliant with [RFC7235]. The enterprise edge element and capability
server MUST support the use of the HTTPS uri scheme as defined in RFC server MUST support the use of the HTTPS uri scheme as defined in
7230 (https://tools.ietf.org/html/rfc7230). [RFC7230].
4.3. Authenticated Client Identity 4.3. Authenticated Client Identity
HTTP usually adopts asymmetric methods of authentication. For HTTP usually adopts asymmetric methods of authentication. For
example, clients typically use certificate based authentication to example, clients typically use certificate based authentication to
verify the server they are talking to, whereas, servers typically use verify the server they are talking to, whereas, servers typically use
methods such as HTTP digest authentication or OAuth2.0 to methods such as HTTP digest authentication or OAuth2.0 to
authenticate clients. Though OAuth2.0 is not an authentication authenticate clients. Though OAuth2.0 is not an authentication
protocol, it nonetheless allows for client authentication to be protocol, it nonetheless allows for client authentication to be
carried out with the use of OAuth tokens. carried out with the use of OAuth tokens.
skipping to change at page 11, line 42 skipping to change at page 11, line 42
2. Discovery using the Webfinger Protocol 2. Discovery using the Webfinger Protocol
The complete HTTPS URLs to be used when authenticating the enterprise The complete HTTPS URLs to be used when authenticating the enterprise
edge element (optional) and obtaining the SIP service provider edge element (optional) and obtaining the SIP service provider
capability set can be obtained from the SIP service provider capability set can be obtained from the SIP service provider
beforehand and entered into the edge element manually via some beforehand and entered into the edge element manually via some
interface - for example, a CLI or GUI. interface - for example, a CLI or GUI.
However, if the resource URL is unknown to the administrator (and by However, if the resource URL is unknown to the administrator (and by
extension of that to the edge element), the WebFinger protocol RFC extension of that to the edge element), the WebFinger protocol
7033 (https://tools.ietf.org/html/rfc5764) may be leveraged. [RFC7033] may be leveraged.
If an enterprise edge element attempts to discover the URL of the If an enterprise edge element attempts to discover the URL of the
endpoints hosted in the ssp1.example.com domain, it issues the endpoints hosted in the ssp1.example.com domain, it issues the
following request (line wraps are for display purposes only). following request (line wraps are for display purposes only).
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=http%3A%2F%2Fssp1.example.com resource=http%3A%2F%2Fssp1.example.com
rel=capabilitySet rel=capabilitySet
HTTP/1.1 HTTP/1.1
Host: ssp1.example.com Host: ssp1.example.com
skipping to change at page 28, line 13 skipping to change at page 28, line 13
a value of 0/false indicates that the service provider network does a value of 0/false indicates that the service provider network does
not require the enterprise network to send the first media packet. not require the enterprise network to send the first media packet.
While the practise of preserving the enterprise network in a While the practise of preserving the enterprise network in a
hairpinned call flow is fairly common, it is recommended that SIP hairpinned call flow is fairly common, it is recommended that SIP
service providers avoid this practise. In the context of a service providers avoid this practise. In the context of a
hairpinned call, the enterprise device retained in the call flow can hairpinned call, the enterprise device retained in the call flow can
easily eavesdrop on the conversation between the offnet parties. easily eavesdrop on the conversation between the offnet parties.
*symmetricRTP*: A leaf node indicating whether the SIP service *symmetricRTP*: A leaf node indicating whether the SIP service
provider expects the enterprise network to use symmetric RTP as provider expects the enterprise network to use symmetric RTP as
defined in RFC 4961 (https://tools.ietf.org/html/rfc4961). defined in [RFC4961]. Uncovering this expectation is useful in
Uncovering this expectation is useful in scenarios where "latching" scenarios where "latching" [RFC7362] is implemented in the service
[RFC7362] is implemented in the service provider network. This node provider network. This node is a Boolean type, a value of 1/true
is a Boolean type, a value of 1/true indicates that the service indicates that the service provider expects the enterprise network to
provider expects the enterprise network to use symmetric RTP, whereas use symmetric RTP, whereas a value of 0/false indicates that the
a value of 0/false indicates that the enterprise network can use enterprise network can use asymmetric RTP.
asymmetric RTP.
*rtcp*: A container that encapsulates generic characteristics of RTCP *rtcp*: A container that encapsulates generic characteristics of RTCP
sessions between the enterprise and service provider network. This sessions between the enterprise and service provider network. This
node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf node is a container for the "RTCPFeedback" and "SymmetricRTCP" leaf
nodes. nodes.
*RTCPFeedback*: A leaf node that indicates whether the SIP service *RTCPFeedback*: A leaf node that indicates whether the SIP service
provider supports the RTP profile extension for RTCP-based feedback provider supports the RTP profile extension for RTCP-based feedback
RFC 4585 (https://tools.ietf.org/html/rfc4585). Media sessions [RFC4585]. Media sessions spanning enterprise and service provider
spanning enterprise and service provider networks, are rarely made to networks, are rarely made to flow directly between the caller and
flow directly between the caller and callee, rather, it is often the callee, rather, it is often the case that media traffic flows through
case that media traffic flows through network intermediaries such as network intermediaries such as SBCs. As a result, RTCP traffic from
SBCs. As a result, RTCP traffic from the service provider network is the service provider network is intercepted by these intermediaries,
intercepted by these intermediaries, which in turn can either pass which in turn can either pass across RTCP traffic unmodified or
across RTCP traffic unmodified or modify RTCP traffic before it is modify RTCP traffic before it is forwarded to the endpoint in the
forwarded to the endpoint in the enterprise network. Modification of enterprise network. Modification of RTCP traffic would be required,
RTCP traffic would be required, for example, if the intermediary has for example, if the intermediary has performed media payload
performed media payload transformation operations such as transcoding transformation operations such as transcoding or transrating. In a
or transrating. In a similar vein, for the RTCP-based feedback similar vein, for the RTCP-based feedback mechanism as defined in
mechanism as defined in RFC 4585 (https://tools.ietf.org/html/ [RFC4585] to be truly effective, intermediaries must ensure that
rfc4585) to be truly effective, intermediaries must ensure that
feedback messages are passed reliably and with the correct formatting feedback messages are passed reliably and with the correct formatting
to enterprise endpoints. This might require additional configuration to enterprise endpoints. This might require additional configuration
and considerations that need to be dealt with at the time of and considerations that need to be dealt with at the time of
provisioning the intermediary device. This node is a Boolean type, a provisioning the intermediary device. This node is a Boolean type, a
value of 1/true indicates that the service provider supports the RTP value of 1/true indicates that the service provider supports the RTP
profile extension for RTP-based feedback and a value of 0/false profile extension for RTP-based feedback and a value of 0/false
indicates that the service provider does not support the RTP profile indicates that the service provider does not support the RTP profile
extension for RTP-based feedback. extension for RTP-based feedback.
*symmetricRTCP*: A leaf node indicating whether the SIP service *symmetricRTCP*: A leaf node indicating whether the SIP service
provider expects the enterprise network to use symmetric RTCP as provider expects the enterprise network to use symmetric RTCP as
defined in RFC 4961 (https://tools.ietf.org/html/rfc4961). This node defined in [RFC4961]. This node is a Boolean type, a value of 1
is a Boolean type, a value of 1 indicates that the service provider indicates that the service provider expects symmetric RTCP reports,
expects symmetric RTCP reports, whereas a value of 0 indicates that whereas a value of 0 indicates that the enterprise can use asymmetric
the enterprise can use asymmetric RTCP. RTCP.
*dtmf*: A container that describes the various aspects of DTMF relay *dtmf*: A container that describes the various aspects of DTMF relay
via RTP Named Telephony Events. The dtmf container allows SIP via RTP Named Telephony Events. The dtmf container allows SIP
service providers to specify two facets of DTMF relay via Named service providers to specify two facets of DTMF relay via Named
Telephony Events: Telephony Events:
1. The payload type number using the payloadNumber leaf node. 1. The payload type number using the payloadNumber leaf node.
2. Support for RFC 2833 (https://tools.ietf.org/html/rfc2833) or RFC 2. Support for [RFC2833] or [RFC4733] using the iteration leaf node.
4733 (https://tools.ietf.org/html/rfc4733) using the iteration
leaf node.
In the context of named telephony events, senders and receivers may In the context of named telephony events, senders and receivers may
negotiate asymmetric payload type numbers. For example, the sender negotiate asymmetric payload type numbers. For example, the sender
might advertise payload type number 97 and the receiver might might advertise payload type number 97 and the receiver might
advertise payload type number 101. In such instances, it is either advertise payload type number 101. In such instances, it is either
required for middleboxes to interwork payload type numbers or allow required for middleboxes to interwork payload type numbers or allow
the endpoints to send and receive asymmetric payload numbers. The the endpoints to send and receive asymmetric payload numbers. The
behaviour of middleboxes in this context is largely dependent on behaviour of middleboxes in this context is largely dependent on
endpoint capabilities or on service provider constraints. Therefore, endpoint capabilities or on service provider constraints. Therefore,
the payloadNumber leaf node can be used to determine middlebox the payloadNumber leaf node can be used to determine middlebox
configuration before-hand. configuration before-hand.
RFC 4733 (https://tools.ietf.org/html/rfc4733) iterates over RFC 2833 [RFC4733] iterates over [RFC2833] by introducing certain changes in
(https://tools.ietf.org/html/rfc2833) by introducing certain changes the way NTE events are transmitted. SIP service providers can
in the way NTE events are transmitted. SIP service providers can indicate support for [RFC4733] by setting the iteration flag to 1 or
indicate support for RFC 4733 (https://tools.ietf.org/html/rfc4733) indicating support for [RFC2833] by setting the iteration flag to 0.
by setting the iteration flag to 1 or indicating support for RFC 2833
(https://tools.ietf.org/html/rfc2833) by setting the iteration flag
to 0.
*security*: A container that encapsulates characteristics about *security*: A container that encapsulates characteristics about
encrypting signalling streams between the enterprise and SIP service encrypting signalling streams between the enterprise and SIP service
provider networks. provider networks.
*signaling*: A container that encapsulates the type of security *signaling*: A container that encapsulates the type of security
protocol for the SIP communication between the enterprise SBC and the protocol for the SIP communication between the enterprise SBC and the
service provider. service provider.
*type*: A leaf node that specifies the protocol used for protecting *type*: A leaf node that specifies the protocol used for protecting
skipping to change at page 30, line 21 skipping to change at page 30, line 18
support TLS for protecting SIP sessions, the signalling element is support TLS for protecting SIP sessions, the signalling element is
set to the string "NULL". set to the string "NULL".
*mediaSecurity*: A container that describes the various *mediaSecurity*: A container that describes the various
characteristics of securing media streams between enterprise and characteristics of securing media streams between enterprise and
service provider networks. service provider networks.
*keyManagement*: A leaf node that specifies the key management method *keyManagement*: A leaf node that specifies the key management method
used by the service provider. Possible values of this node include: used by the service provider. Possible values of this node include:
"SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP "SDES" and "DTLS-SRTP". A value of "SDES" signifies that the SIP
service provider uses the methods defined in RFC 4568 service provider uses the methods defined in [RFC4568] for the
(https://tools.ietf.org/html/rfc4568) for the purpose of key purpose of key management. A value of "DTLS-SRTP" signifies that the
management. A value of "DTLS-SRTP" signifies that the SIP service SIP service provider uses the methods defined in [RFC5764]for the
provider uses the methods defined in RFC 5764 purpose of key management. If the value of this leaf node is set to
(https://tools.ietf.org/html/rfc5764) for the purpose of key "DTLS-SRTP", the various versions of DTLS supported by the SIP
management. If the value of this leaf node is set to "DTLS-SRTP", service provider MUST be encoded as per the formatting rules of
the various versions of DTLS supported by the SIP service provider Section 9.2. If the service provider does not support media
MUST be encoded as per the formatting rules of Section 9.2. If the security, the keyManagement node MUST be set to "NULL".
service provider does not support media security, the keyManagement
node MUST be set to "NULL".
*certLocation:*: If the enterprise network is required to exchange *certLocation:*: If the enterprise network is required to exchange
SIP traffic over TLS with the SIP service provider, and if the SIP SIP traffic over TLS with the SIP service provider, and if the SIP
service provider is capable of accepting TLS connections from the service provider is capable of accepting TLS connections from the
enterprise network, it may be required for the SIP service provider enterprise network, it may be required for the SIP service provider
certificates to be pre-installed on the enterprise edge element. In certificates to be pre-installed on the enterprise edge element. In
such situations, the certLocation leaf node is populated with a URL, such situations, the certLocation leaf node is populated with a URL,
which when dereferenced, provides a single PEM encoded file that which when dereferenced, provides a single PEM encoded file that
contains all certificates in the chain of trust. This is an optional contains all certificates in the chain of trust. This is an optional
leaf node. leaf node.
skipping to change at page 32, line 8 skipping to change at page 31, line 40
MUST only be included in the capability set if the value of the MUST only be included in the capability set if the value of the
STIRCompliance leaf node is set to 1/true. In order to obtain STIRCompliance leaf node is set to 1/true. In order to obtain
delegate certificates, the enterprise network must be made aware of delegate certificates, the enterprise network must be made aware of
the scope of delegation - the number or number range(s) over which the scope of delegation - the number or number range(s) over which
the SIP service provider is willing to delegate authority. This the SIP service provider is willing to delegate authority. This
information is included in the numRange container. information is included in the numRange container.
*ACMEDirectory*: For delegate certificates that are obtained by the *ACMEDirectory*: For delegate certificates that are obtained by the
enterprise network using Automatic Certificate Management Environment enterprise network using Automatic Certificate Management Environment
(ACME), this leaf node value provides the URL of the directory object (ACME), this leaf node value provides the URL of the directory object
(https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme- [ACME]. The directory object URL, when de-referenced, provides a
18#section-7.1.1). The directory object URL, when de-referenced, collection of field name-value pairs. Certain field name-value pairs
provides a collection of field name-value pairs. Certain field name- provided in the response are used to bootstrap the process the
value pairs provided in the response are used to bootstrap the obtaining delegate certificates. This leaf node MUST only be
process the obtaining delegate certificates. This leaf node MUST included in the capability set if the value of the certDelegation
only be included in the capability set if the value of the leaf node is set to 1/true.
certDelegation leaf node is set to 1/true.
*extensions*: A leaf node that is a semicolon separated list of all *extensions*: A leaf node that is a semicolon separated list of all
possible SIP option tags supported by the service provider network. possible SIP option tags supported by the service provider network.
These extensions must be referenced using name registered under IANA. These extensions must be referenced using name registered under IANA.
If the service provider network does not support any extensions to If the service provider network does not support any extensions to
baseline SIP, the extensions node must be set to "NULL". baseline SIP, the extensions node must be set to "NULL".
7.4. Extending the Capability Set 7.4. Extending the Capability Set
There are situations in which equipment manufactures or service There are situations in which equipment manufactures or service
skipping to change at page 37, line 7 skipping to change at page 36, line 26
10. Security Considerations 10. Security Considerations
[TBD] [TBD]
11. Acknowledgments 11. Acknowledgments
[TBD] [TBD]
12. Normative References 12. Normative References
[ACME] "Automatic Certificate Management Environment",
<https://datatracker.ietf.org/doc/html/draft-ietf-acme-
acme-18#section-7.1.1>.
[BCP-14] "Key words for use in RFCs to Indicate Requirement
Levels", <https://www.rfc-editor.org/info/bcp14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833, Digits, Telephony Tones and Telephony Signals", RFC 2833,
DOI 10.17487/RFC2833, May 2000, DOI 10.17487/RFC2833, May 2000,
<https://www.rfc-editor.org/info/rfc2833>. <https://www.rfc-editor.org/info/rfc2833>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/info/rfc4568>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006, DOI 10.17487/RFC4733, December 2006,
<https://www.rfc-editor.org/info/rfc4733>. <https://www.rfc-editor.org/info/rfc4733>.
skipping to change at page 37, line 47 skipping to change at page 37, line 29
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<https://www.rfc-editor.org/info/rfc4961>. <https://www.rfc-editor.org/info/rfc4961>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 38, line 31 skipping to change at page 38, line 18
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>. 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/info/rfc7092>. <https://www.rfc-editor.org/info/rfc7092>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
 End of changes. 17 change blocks. 
62 lines changed or deleted 74 lines changed or added

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