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]