draft-ietf-avtext-sdes-hdr-ext-06.txt   draft-ietf-avtext-sdes-hdr-ext-07.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft B. Burman Internet-Draft B. Burman
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: October 28, 2016 R. Even Expires: December 12, 2016 R. Even
Huawei Technologies Huawei Technologies
M. Zanaty M. Zanaty
Cisco Systems Cisco Systems
April 26, 2016 June 10, 2016
RTP Header Extension for RTCP Source Description Items RTP Header Extension for RTCP Source Description Items
draft-ietf-avtext-sdes-hdr-ext-06 draft-ietf-avtext-sdes-hdr-ext-07
Abstract Abstract
Source Description (SDES) items are normally transported in RTP Source Description (SDES) items are normally transported in RTP
control protocol (RTCP). In some cases it can be beneficial to speed control protocol (RTCP). In some cases it can be beneficial to speed
up the delivery of these items. Mainly when a new source (SSRC) up the delivery of these items. Mainly when a new source (SSRC)
joins an RTP session and the receivers needs this source's identity, joins an RTP session and the receivers need this source's identity,
relation to other sources, or its synchronization context, all of relation to other sources, or its synchronization context, all of
which may be fully or partially identified using SDES items. To which may be fully or partially identified using SDES items. To
enable this optimization, this document specifies a new RTP header enable this optimization, this document specifies a new RTP header
extension that can carry SDES items. extension that can carry SDES items.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 28, 2016. This Internet-Draft will expire on December 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 30 skipping to change at page 2, line 30
4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5
4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6
4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6 4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7
4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 4.2.3. Transmission Considerations . . . . . . . . . . . . . 7
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11 5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11
5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11 5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11
5.3. Registration of SDES Items . . . . . . . . . . . . . . . 12 5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This specification defines an RTP header extension [RFC3550][RFC5285] This specification defines an RTP header extension [RFC3550][RFC5285]
that can carry RTCP source description (SDES) items. Normally the that can carry RTCP source description (SDES) items. Normally the
SDES items are carried in their own RTCP packet type [RFC3550]. By SDES items are carried in their own RTCP packet type [RFC3550]. By
including selected SDES items in a header extension the determination including selected SDES items in a header extension the determination
of relationship and synchronization context for new RTP streams of relationship and synchronization context for new RTP streams
(SSRCs) in an RTP session can be optimized. Which relationship and (SSRCs) in an RTP session can be optimized. Which relationship and
what information depends on the SDES items carried. This becomes a what information depends on the SDES items carried. This becomes a
skipping to change at page 4, line 51 skipping to change at page 4, line 51
determine the benefit of reducing the initial delay before determine the benefit of reducing the initial delay before
information is available for some use cases. information is available for some use cases.
Rapid Synchronization of RTP Flows [RFC6051] also discusses the case Rapid Synchronization of RTP Flows [RFC6051] also discusses the case
of late joiners, and defines an RTCP Feedback format to request of late joiners, and defines an RTCP Feedback format to request
synchronization information, which is another potential use case for synchronization information, which is another potential use case for
SDES items in RTP header extension. It would for example be natural SDES items in RTP header extension. It would for example be natural
to include CNAME SDES item with the header extension containing the to include CNAME SDES item with the header extension containing the
NTP formatted reference clock to ensure synchronization. NTP formatted reference clock to ensure synchronization.
There is an another SDES item that can benefit from timely delivery, The ongoing work on bundling SDP media descriptions
and an RTP header extension SDES item was therefore defined for it: [I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES
item that can benefit from timely delivery. A corresponding RTP SDES
compact header extension is therefore also defined and registered in
that document:
MID: This is a media description identifier that matches the value MID: This is a media description identifier that matches the value
of the Session Description Protocol (SDP) [RFC4566] a=mid of the Session Description Protocol (SDP) [RFC4566] a=mid
attribute, to associate RTP streams multiplexed on the same attribute [RFC5888], to associate RTP streams multiplexed on the
transport with their respective SDP media description as described same transport with their respective SDP media description.
in [I-D.ietf-mmusic-sdp-bundle-negotiation].
4. Specification 4. Specification
This section first specifies the SDES item RTP header extension This section first specifies the SDES item RTP header extension
format, followed by some usage considerations. format, followed by some usage considerations.
4.1. SDES Item Header Extension 4.1. SDES Item Header Extension
An RTP header extension scheme allowing for multiple extensions is An RTP header extension scheme allowing for multiple extensions is
defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. defined in "A General Mechanism for RTP Header Extensions" [RFC5285].
skipping to change at page 5, line 40 skipping to change at page 5, line 42
using a URN, which is defined in the IANA consideration (Section 5) using a URN, which is defined in the IANA consideration (Section 5)
for the known SDES items appropriate to use. for the known SDES items appropriate to use.
4.1.1. One-Byte Format 4.1.1. One-Byte Format
The one-byte header format for an SDES item extension element The one-byte header format for an SDES item extension element
consists of the one-byte header (defined in Section 4.2 of consists of the one-byte header (defined in Section 4.2 of
[RFC5285]), which consists of a 4-bit ID followed by a 4-bit length [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length
field (len) that identifies the number of data bytes (len value +1) field (len) that identifies the number of data bytes (len value +1)
following the header. The data part consists of len+1 bytes of UTF-8 following the header. The data part consists of len+1 bytes of UTF-8
text. The type of text and its mapping to the SDES item type is [RFC3629] text. The type of text and its mapping to the SDES item
determined by the ID field value. type is determined by the ID field value.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES Item text value ... | | ID | len | SDES Item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
4.1.2. Two-Byte Format 4.1.2. Two-Byte Format
skipping to change at page 10, line 46 skipping to change at page 10, line 46
packets, which will contain a Sender Report (SR) packet (assuming an packets, which will contain a Sender Report (SR) packet (assuming an
active RTP sender), the receiver can use the RTCP SR Timestamp field active RTP sender), the receiver can use the RTCP SR Timestamp field
to determine at what approximate time it was transmitted. If the to determine at what approximate time it was transmitted. If the
timestamp is earlier than the last received RTP packet with a header timestamp is earlier than the last received RTP packet with a header
extension carrying an SDES item, and especially if carrying a extension carrying an SDES item, and especially if carrying a
previously used value, the SDES item in the RTCP SDES packet can be previously used value, the SDES item in the RTCP SDES packet can be
ignored. Note that media processing and transmission pacing can ignored. Note that media processing and transmission pacing can
easily cause the RTP header timestamp field as well as the RTCP SR easily cause the RTP header timestamp field as well as the RTCP SR
timestamp field to not match with the actual transmission time. timestamp field to not match with the actual transmission time.
4.2.7. RTP Header Compression
When robust header compression (ROHC) [RFC5225] is used with RTP, the
RTP header extension [RFC5285] data itself is not part of what is
being compressed and thus does not impact header compression
performance. The extension indicator (X) bit in the RTP header is
however compressed. It is classified as rarely changing, which may
no longer be true for all RTP header extension usage, in turn leading
to lower header compression efficiency.
5. IANA Considerations 5. IANA Considerations
This section makes the following requests to IANA: This section makes the following requests to IANA:
o Create a new sub-registry reserved for RTCP SDES items with the o Create a new sub-registry reserved for RTCP SDES items with the
URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP
Compact Header Extensions registry. Compact Header Extensions registry.
o Register the SDES items appropriate for use with the RTP header o Register the SDES items appropriate for use with the RTP header
extension defined in this document. extension defined in this document.
skipping to change at page 12, line 17 skipping to change at page 12, line 26
3. Information MUST be provided on why this SDES item requires 3. Information MUST be provided on why this SDES item requires
timely delivery, motivating it to be transported in a header timely delivery, motivating it to be transported in a header
extension rather than as RTCP only. extension rather than as RTCP only.
o Size and format of entries: Same as for RTP Header Extensions o Size and format of entries: Same as for RTP Header Extensions
[RFC5285] registry. [RFC5285] registry.
o Initial assignments: See Section 5.3 below. o Initial assignments: See Section 5.3 below.
5.3. Registration of SDES Items 5.3. Registration of SDES Item
It is requested that the following SDES item is registered in the It is requested that the following SDES item is registered in the
newly formed RTP SDES Compact Header Extensions registry: newly formed RTP SDES Compact Header Extensions registry:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier Description: Source Description: Canonical End-Point Identifier
(SDES CNAME) (SDES CNAME)
Contact: Authors of [RFCXXXX] Contact: Authors of [RFCXXXX]
Reference: [RFCXXXX] Reference: [RFCXXXX]
skipping to change at page 12, line 47 skipping to change at page 13, line 9
persistence it has. A short term CNAME identifier generated using a persistence it has. A short term CNAME identifier generated using a
random number generator [RFC7022] may have minimal security random number generator [RFC7022] may have minimal security
implications, while a CNAME of the form user@host has privacy implications, while a CNAME of the form user@host has privacy
concerns, and a CNAME generated from a MAC address has long term concerns, and a CNAME generated from a MAC address has long term
tracking potentials. tracking potentials.
In RTP sessions where any type of confidentiality protection is In RTP sessions where any type of confidentiality protection is
enabled for RTCP, the SDES item header extensions MUST also be enabled for RTCP, the SDES item header extensions MUST also be
protected. This implies that to provide confidentiality, users of protected. This implies that to provide confidentiality, users of
SRTP need to implement and use encrypted header extensions per SRTP need to implement and use encrypted header extensions per
[RFC6904]. The security level that is applied to RTCP packets [RFC6904]. SDES items carried as RTP header extensions MUST then use
carrying SDES items SHOULD also be applied to SDES items carried as commensurate strength algorithms and SHOULD use the same
RTP header extensions. If the security level is chosen to be cryptographic primitives (algorithms, modes) as applied to RTCP
different for an SDES item in RTCP and RTP header extension, it is packets carrying corresponding SDES items. If the security level is
important to motivate the exception, and to consider the security chosen to be different for an SDES item in RTCP and RTP header
properties as the worst in each aspect for the different extension, it is important to motivate the exception, and to consider
configurations. the security properties as the worst in each aspect for the different
configurations. It is worth noting that the current Secure RTP
(SRTP) [RFC3711] only provides protection for the next trusted RTP/
RTCP hop, which is not necessarily end-to-end.
The general RTP header extension mechanism [RFC5285] does not itself The general RTP header extension mechanism [RFC5285] does not itself
contain any functionality that is a significant risk for a denial of contain any functionality that is a significant risk for a denial of
service attack, neither from processing nor storage requirements. service attack, neither from processing nor storage requirements.
The extension for SDES items defined, can potentially be a risk. The The extension for SDES items defined in this document, can
risk depends on the received SDES item and its content. If the SDES potentially be a risk. The risk depends on the received SDES item
item causes the receiver to perform a large amount of processing, and its content. If the SDES item causes the receiver to perform a
create significant storage structures, or emit network traffic, such large amount of processing, create significant storage structures, or
a risk does exist. The CNAME SDES item in the RTP header extension emit network traffic, such a risk does exist. The CNAME SDES item in
is only a minor risk, as reception of a CNAME item will create an the RTP header extension is only a minor risk, as reception of a
association between the stream carrying the SDES item and other RTP CNAME item will create an association between the stream carrying the
streams with the same SDES item. This usually results in time SDES item and other RTP streams with the same SDES item. This
synchronizing the media streams, thus some additional processing is usually results in time synchronizing the media streams, thus some
performed. However, the application's media quality is likely more additional processing is performed. However, the application's media
affected by an erroneous or changing association and media quality is likely more affected by an erroneous or changing
synchronization, than the application quality impact caused by the association and media synchronization, than the application quality
additional processing. impact caused by the additional processing.
As the SDES items are used by the RTP based application to establish As the SDES items are used by the RTP based application to establish
relationships between RTP streams or between an RTP stream and relationships between RTP streams or between an RTP stream and
information about the originating participant, there SHOULD be strong information about the originating participant, there SHOULD be strong
integrity protection and source authentication of the header integrity protection and source authentication of the header
extensions. If not, an attacker can modify the SDES item value to extensions. If not, an attacker can modify the SDES item value to
create erroneous relationship bindings in the receiving application. create erroneous relationship bindings in the receiving application.
For information regarding options for securing RTP, see [RFC7201]. For information regarding options for securing RTP, see [RFC7201].
7. Acknowledgments 7. Acknowledgments
skipping to change at page 14, line 20 skipping to change at page 14, line 34
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-29 (work in progress), April 2016. negotiation-30 (work in progress), June 2016.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[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,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008,
<http://www.rfc-editor.org/info/rfc5225>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <http://www.rfc-editor.org/info/rfc5576>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
<http://www.rfc-editor.org/info/rfc6051>. <http://www.rfc-editor.org/info/rfc6051>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>. September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
skipping to change at page 15, line 37 skipping to change at page 16, line 18
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Gronlandsgatan 31
Stockholm 16480 Stockholm 16480
Sweden Sweden
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
 End of changes. 21 change blocks. 
40 lines changed or deleted 75 lines changed or added

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