SIPPING Working Group A. Johnston
Internet-Draft H. Sinnreich
Expires: April 24, 2004 MCI
A. Clark
Telchemy Incorporated
October 24, 2003
RTCP Summary Report Delivery to SIP Third Parties
draft-johnston-sipping-rtcp-summary-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document discusses the motivation and requirements for the
delivery of RTCP extended reports and other summary reports to
non-participants in the session. Several solution mechanisms are
also discussed and compared.
Johnston, et al. Expires December 19, 2003 [Page 1]
Internet-Draft RTCP Summary Delivery October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 4
3.1 Forking RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 SIP Header Field or Message Body . . . . . . . . . . . . . . . 5
3.3 SIP Event Package . . . . . . . . . . . . . . . . . . . . . . 5
4. Proposed Format for Metrics. . . . . . . . . . . . . . . . . . 6
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Johnston, et al. Expires December 19, 2003 [Page 2]
Internet-Draft RTCP Summary Delivery October 2003
1. Introduction
RTP Control Protocol (RTCP) [3] defines Sender Reports (SR) and
Receiver Reports (RR) which are exchanged between the participants in
a media session about the quality of the media session. RTCP
Extended Reports (XR) [4] have also been defined to provide
additional quality information. In particular, two summary reports
are included: a statistics summary report and a VoIP (Voice over IP)
metrics block.
This summary information is of particular interest to certain parties
who may not be participants in the media session. For example, a
service provider might be interested in logging a summary report of
the QoS of a VoIP session. Alternatively, an enterprise might want
to compile a summary of the QoS of multimedia sessions established
over a wide area network.
In the case of a gateway or other high-density device, the device is
likely to implement various protocols and have the ability to log and
export this type of RTCP summary reports. However, this is not
practical in smaller endpoints such as SIP phones, clients, or mobile
phones.
This document discusses the requirements of a mechanism to allow a
third party which is not a participant in a session receive RTCP
summary reports. Three possible mechanisms are discussed at a very
high level.
2. Requirements
REQ-1: An authorized third party should be able to receive selected
RTCP reports on a near real time basis.
REQ-2: The client should not have to store large amounts of
information.
REQ-3: The client must be able to authenticate the third party.
REQ-4: The RTCP report information must be able to be transferred
securely.
REQ-5: Only one participant in the session need support the mechanism
- the participant will send both sent and received summary reports.
REQ-6: The reports will include or be associated with dialog
identifiers for correlation purposes.
Johnston, et al. Expires December 19, 2003 [Page 3]
Internet-Draft RTCP Summary Delivery October 2003
3. Possible Mechanisms
Three possible mechanisms could be used implement these requirements:
o Forking RTCP to multiple locations,
o Carrying RTCP information in a SIP header field or message body,
o Using an events package to delivery RTCP information.
3.1 Forking RTCP
Forking RTCP would involve sending RTCP reports to the third party in
addition to the other participant in the session. In general, one
RTCP session is established per RTP media session. That is, if a
session consists of a voice stream and a video stream, two separate
RTCP sessions will be established in which the participants exchange
QoS and other data. The RTCP reports are sent to the same IP address
as the RTP media but the next higher port number. (There is also an
extension [5] to SDP to explicitly list the RTCP IP address and port
number.) RTCP does exchange useful information between endpoints and
hence redirection of RTCP messages may not be desirable, hence it may
be necessary to both send RTCP between endpoints and to some other
party - i.e. to fork RTCP. There is no current notion of RTCP
reports being sent to multiple IP addresses and hence end points.
An extension to send RTCP reports to multiple locations could be
defined. If this were implemented in an endpoint, the RTCP reports
sent and received in a session could be sent to a third party which
would listen on a particular IP address and port number. It would
also be necessary to define the frequency at which forked RTCP
messages be sent as this may be less often than the exchanges between
endpoints.
An obvious difficulty of this approach is how the third party would
signal this IP address and port number to the endpoint during session
setup. A 3pcc could insert this extra information (in an SDP
extension attribute) in the SDP at the time of call setup. However,
there is no good solution for the peer-to-peer model without forcing
a proxy to act as a B2BUA and modify SDP.
Another drawback is the lack of security in this approach.
This approach would not require any extensions to SIP but may require
extensions to SDP and RTCP for mechanisms to signal the transport IP
address and port number of the third party.
Johnston, et al. Expires December 19, 2003 [Page 4]
Internet-Draft RTCP Summary Delivery October 2003
3.2 SIP Header Field or Message Body
In this approach, the desired RTCP reports could be carried in a SIP
[6] request or response message which would then be available to
proxies which had Record-Routed the dialog. For example, summary
RTCP reports could be carried in a BYE message at the end of the
session. Since the requirement is to make the information available
to intermediary third parties, the information would best be carried
in a header field rather than a message body. The compact nature of
the binary encoded reports would not rule out inclusion in a header
field.
The main disadvantage of this approach is that any third parties
would need to Record-Route in order to receive the reports. Also, if
the header field were only transported in an S/MIME encrypted message
body, the information would not be available to the intermediaries.
Finally, while the inclusion of this information at the end of a
session in a BYE seems a good choice, there is no good candidates for
mid-session delivery of this information (INFO would NOT be a good
choice for this) although a re-INVITE could be used.
3.3 SIP Event Package
In this approach, a new SIP events package [6] would be defined. A
third party could subscribe to the participant to receive
notifications of RTCP reports transported using the NOTIFY method.
An advantage of this approach is that the third party does not need
to be a proxy that has Record-Routed a particular dialog. The
SUBSCRIBE request from the third party can use any of the set of
standard SIP authentication mechanisms to authorize the third party.
In addition, the reports transported using NOTIFY can use TLS or S/
MIME to secure the transport of the report data.
During the establishment of the subscription, the third party could
request the type and frequency of RTCP reports. The event package
could also define the rate limitations.
The subscription could either be for a particular dialog, in which
the subscription would expire at the termination of the session. The
third party could then subscribe to the dialog package to receive
notifications whenever the endpoint began a new session, providing
the third party the information about the session sufficient to make
a decision as to whether to subscribe to the RTCP report package for
this particular dialog. Alternatively, the subscription could be
temporally bound in which the third party would receive notifications
from all dialogs until the subscription expired.
Johnston, et al. Expires December 19, 2003 [Page 5]
Internet-Draft RTCP Summary Delivery October 2003
A disadvantage of this approach is that that the endpoint must manage
the subscription and support SIP events and the RTCP report event
package. A third party wishing to receive reports from multiple
endpoints would need manage multiple subscriptions.
4. Proposed Format for Metrics
It is proposed that the endpoint report the RTCP XR VoIP Metrics [4]
Section 4.7. These would be encoded in comma separated ASCII Hex
representation as:
Source SSRC HHHHHHHH (32 bit integer)
The SSRC of the originator of this message, included to facilitate
correlation with other data.
Packet Loss Rate HH (8 bit integer)
The fraction of packets lost within the network.
Packet Discard Rate HH (8 bit integer)
The fraction of packets discarded due to jitter.
Burst Loss Density HH (8 bit integer)
The fraction of packets lost and discarded within a
burst (high loss rate) period.
Burst Length (mS) HHHH (16 bit integer)
The mean length of a burst.
Gap Loss Density HH (8 bit integer)
The fraction of packets lost and discarded within a
gap (low loss rate) period.
Gap Length (mS) HHHH (16 bit integer)
The mean length of a gap
RTP Round Trip Delay (mS) HHHH (16 bit integer)
The round trip delay between RTP interfaces
End System Round Trip Delay (mS) HHHH (16 bit integer)
The "round trip" delay between the RTP interface and the
analog or trunk interface.
Signal Level (dBm) HH (8 bit integer)
The signal level during talkspurts.
Noise Level (dBm) HH (8 bit integer)
The signal level during silence periods.
Residual Echo Return Loss (dB) HH (8 bit integer)
The residual (uncancelled) echo level from the analog or
trunk interface.
Johnston, et al. Expires December 19, 2003 [Page 6]
Internet-Draft RTCP Summary Delivery October 2003
Gmin HH (8 bit integer)
A parameter used in the definition of bursts (typically 16)
R Factor HH (8 bit integer)
Estimated conversational call quality expressed in R factor
terms.
External R Factor HH (8 bit integer)
An estimate of the call quality from an externally attached
network.
MOS-LQ HH (8 bit integer)
Estimated listening call quality expressed as a MOS score
MOS-CQ HH (8 bit integer)
Estimated conversational call quality expressed as a MOS score
Receiver Configuration HH (8 bit integer)
PLC algorithm and jitter buffer types.
Jitter Buffer Nominal Delay (mS) HHHH (16 bit integer)
The mean jitter buffer delay.
Jitter Buffer Maximum Delay (mS) HHHH (16 bit integer)
The maximum delay that an arriving packet could incur with the
current jitter buffer size.
Jitter Buffer Absolute Max Delay (mS) HHHH (16 bit int)
The maximum size that an adaptive jitter buffer could grow to.
As RTCP XR does not mandate that all values are provided, it is
proposed that a parameter value is simply left out if not available.
For example:
AF8E9FF0, 00, 05,,,05,1F3C,0064,0028,,,,10,55,,24,23,F0,,001E,003C,00C8
indicates that for the session originating from this SIP device that
had SSRC=AF8E9FF0 then the packet loss rate was zero, the packet discard
rate (due to jitter) was 2%, there were no bursts, the gap loss/discard
rate was 2%, the RTP round trip delay was 100mS, the end system delay
was 40mS, Gmin was 16, the R factor was 85, the MOS-LQ 3.6, the MOS-CQ
3.5, the endpoint used a standard PLC algorithm and a 200mS adaptive
jitter buffer with average delay 30mS and max delay 60 mS.
Johnston, et al. Expires December 19, 2003 [Page 7]
Internet-Draft RTCP Summary Delivery October 2003
5. Conclusions
Based on these approaches, the SIP event package seems like the best
approach for overall flexibility, robustness, and security. The next
step is for detailed requirements for the new SIP event package to be
developed.
6. Security Considerations
RTCP reports can contain sensitive information since they can provide
information about the nature and duration of a session established
between two endpoints. As a result, any third party wishing to
obtain this information should be properly authenticated and the
information transferred securely.
7. Contributors
The authors would like to thank Dave Oran and Tom Redman for their
contributions on the merits of the various approaches discussed here.
Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[4] Friedman, T., "RTP Control Protocol Extended Reports (RTCP XR)",
draft-ietf-avt-rtcp-report-extns-06 (work in progress), May
2003. ("RFC to be" 3611)
[5] Huitema, C., "RTCP attribute in SDP",
draft-ietf-mmusic-sdp4nat-05 (work in progress), June 2003.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Johnston, et al. Expires December 19, 2003 [Page 8]
Internet-Draft RTCP Summary Delivery October 2003
Authors' Addresses
Alan Johnston
MCI
100 South 4th Street
St. Louis, MO 63104
EMail: alan.johnston@mci.com
Henry Sinnreich
MCI
400 International Parkway
Richardson, TX 75081
EMail: henry.sinnreich@mci.com
Alan Clark
Telchemy Incorporated
3360 Martins Farm Road, Suite 200
Suwanee, GA 30024
EMail: alan@telchemy.com
Johnston, et al. Expires December 19, 2003 [Page 9]
Internet-Draft RTCP Summary Delivery October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Johnston, et al. Expires December 19, 2003 [Page 10]
Internet-Draft RTCP Summary Delivery October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Johnston, et al. Expires December 19, 2003 [Page 11]