SIPPING Working Group A. Johnston Internet-Draft H. Sinnreich Expires: August 15, 2004 MCI A. Clark Telchemy Incorporated A. Pendleton Nortel Networks February 15, 2004 RTCP Summary Report Delivery to Third Parties draft-johnston-sipping-rtcp-summary-02 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 August 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). 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. A SIP events package is proposed as a solution. An event package "rtcp-xr" is defined in this document along with some example call flows. Johnston, et al. Expires August 15, 2004 [Page 1] Internet-Draft RTCP Summary Delivery February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 4 3.1 Forking RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 SIP Header Field or Message Body . . . . . . . . . . . . . . . 5 3.4 SIP Event Package . . . . . . . . . . . . . . . . . . . . . . 5 4. Event Package Formal Definition . . . . . . . . . . . . . . . 6 4.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Event Package Parameters . . . . . . . . . . . . . . . . . . . 6 4.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Subscription Duration . . . . . . . . . . . . . . . . . . . . 7 4.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6 Metric Definitions . . . . . . . . . . . . . . . . . . . . . . 9 4.7 Format Example . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . . 11 5.1 End of Session Notification Call Flow . . . . . . . . . . . . 11 5.2 Mid Session Report . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Johnston, et al. Expires August 15, 2004 [Page 2] Internet-Draft RTCP Summary Delivery February 2004 1. Introduction There is a general need for real-time reporting of session quality in enterprise and service provider networks. While the approach discussed in this document is quite general, this document is limited in scope to the delivery of particular RTCP summary reports. 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 AAA 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. The SIP events approach is found to be the best solution, and an event package is defined. Some sample call flows are also included. 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. Johnston, et al. Expires August 15, 2004 [Page 3] Internet-Draft RTCP Summary Delivery February 2004 REQ-5: A client participating in a bi-directional session will store and send RTCP summary reports for both directions. REQ-6: The reports will include or be associated with dialog identifiers for correlation purposes. 3. Possible Mechanisms Four possible mechanisms could be used implement these requirements: o Forking RTCP to multiple locations, o SNMP, 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 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.) While RFC3550 (RTP/RTCP) proposes multicasting RTCP sessions, what is missing is a mechanism for communicating correlation identifiers for purposes of determining which reports are associated with each other, particularly where source/dest IP/port are not globally unique. Also, there is not a means for establishing an association between the session participants and a collector. In addition, authentication also not covered. 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. 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 Johnston, et al. Expires August 15, 2004 [Page 4] Internet-Draft RTCP Summary Delivery February 2004 address and port number of the third party. 3.2 SNMP Since this type of QoS monitoring seems related to management, SNMP could possibly be used to collect this type of data. In general, SNMP may be used to manage the SIP user agent - the phone, soft phone or gateway. However, the information available in RTCP summary reports is of less interest to the management of the UA and more of interest to the VoIP service provider. In many cases, separate entities will be involved. For example, an enterprise may manage their own SIP phones using SNMP, but a service provider provides SIP and gateway services. It is unlikely a service provider will have SNMP privileges and may not be able to manage NAT/firewall traversal, etc. For these reasons, SNMP is not a good fit for this "service level" management function. The next two approaches are closely coupled to SIP, which overcomes the disadvantages of the non-SIP approaches. 3.3 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.4 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 Johnston, et al. Expires August 15, 2004 [Page 5] Internet-Draft RTCP Summary Delivery February 2004 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. 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 to manage multiple subscriptions. 4. Event Package Formal Definition 4.1 Event Package Name This document defines a SIP Event Package as defined in RFC 3265 [2]. The event-package token name for this package is: "rtcp-xr" OPEN ISSUE: Should a more general name be used so that different message bodies can be defined to carry different session information? 4.2 Event Package Parameters The event package parameter "threshold" if present indicates that the subscriber wishes to receive mid-session threshold reports. That is, if the quality of the session degrades beyond a locally configured value during a session, the notifier should send a NOTIFY message. If the event package is not present, the default is not to send the threshold reports, but to send a single NOTIFY at the end of each media session. Johnston, et al. Expires August 15, 2004 [Page 6] Internet-Draft RTCP Summary Delivery February 2004 OPEN ISSUE: Is this the best way to do this or should a filter message body be defined? OPEN ISSUE: Ideally, the threshold value could be negotiated during the establishment of the subscription, but this seems hard. 4.3 SUBSCRIBE Bodies No SUBSCRIBE bodies are described by this specification. 4.4 Subscription Duration Subscriptions to this event package MAY range from minutes to weeks. Subscriptions in hours or days are more typical and are RECOMMENDED. The default subscription duration for this event package is one hour. 4.5 NOTIFY Bodies There are two notify bodies: a general report and a threshold report. The general report is used for periodic, mid-call reporting and end of call reporting. The general report can include both local and remote metrics. The threshold report is used when call quality degrades. The general report is also included in the alert report to provide all of the necessary diagnostic information. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [7]. OPEN ISSUE: The message body should probably be a MIME type. General Report Event: VQEvent = LocalMetrics CLRF RemoteMetrics LocalMetrics = ("LocalMetrics") HCOLON VoiceQualityMetrics RemoteMetrics = ("RemoteMetrics") HCOLON VoiceQualityMetrics VoiceQualityMetrics = ("VQMetrics") HCOLON CLRF PacketLossMetrics CRLF BurstMetrics CLRF GapMetrics CLRF DelayMetrics CLRF SignalMetrics CLRF QualityScores CLRF Johnston, et al. Expires August 15, 2004 [Page 7] Internet-Draft RTCP Summary Delivery February 2004 PacketLossMetrics = ("plm") EQUALS loss-rate SPACE discard-rate loss-rate = ("loss") HCOLON HEX (HH) discard rate = ("disc") HCOLON HEX (HH) BurstMetrics = ("burst") EQUALS density SPACE length GapMetrics = ("gap") EQUALS density SPACE length density = ("den") HCOLON HEX (HH) length = ("len") HCOLON HEX (HHHH) DelayMetrics = ("delay") EQUALS round-trip SPACE end-system round-trip = ("rt") COLON HEX (HHHH) end-system = ("es") COLON HEX (HHHH) SignalMetrics = ("signal") EQUALS signal SPACE echo-return-loss SPACE noise signal = ("sig") HCOLON HEX (HH) echo-return-loss = ("erl") HCOLON HEX (HH) noise = ("n") HCOLON HEX (HH) QualityScores = ("qs") EQUALS r-factor SPACE ext-r-factor SPACE mos-lq SPACE mos-cq r-factor = ("r") HCOLON HEX (HH) ext-r-factor = ("xr") HCOLON HEX (HH) mos-lq = ("ml") HCOLON HEX (H"."H) mos-cq = ("mc") HCOLON HEX (H"."H) DialogID = ("DialogID") HCOLON callid *(SEMI dialogid-param) dialogid-param = to-tag / from-tag / generic-param callid = token to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token Alert Format: VoiceQualityAlert = ("VQAlert") HCOLON SPACE ViolationMetric CRLF VoiceQualityMetrics ViolationMetric = ("AlertType") HCOLON ("rf"| "burst" | "erl" | "delay" token ) OPEN ISSUE: Is this format human readable enough? Johnston, et al. Expires August 15, 2004 [Page 8] Internet-Draft RTCP Summary Delivery February 2004 4.6 Metric Definitions See RFC 3611 [4] for a full description of these metrics. Packet Loss Ratio The fraction of packets lost within the network. Packet Discard Rate The fraction of packets discarded due to jitter. Burst Density The fraction of packets lost and discarded within a burst (high loss rate) period. Burst Length (mS) The mean length of a burst. Gap Density The fraction of packets lost and discarded within a gap (low loss rate) period. Gap Length (mS) The mean length of a gap Round Trip Delay (mS) The round trip delay between RTP interfaces End System Round Trip Delay (mS) The "round trip" delay between the RTP interface and the analog or trunk interface. Signal Level (dBm) The signal level during talkspurts. Noise Level (dBm) The signal level during silence periods. Residual Echo Return Loss (dB) The residual (uncancelled) echo level from the analog or trunk interface. R Factor Estimated conversational call quality expressed in R factor terms. External R Factor An estimate of the call quality from an externally attached Johnston, et al. Expires August 15, 2004 [Page 9] Internet-Draft RTCP Summary Delivery February 2004 network. MOS-LQ Estimated listening call quality expressed as a MOS score MOS-CQ Estimated conversational call quality expressed as a MOS score 4.7 Format Example Call Alert Scenario NOTIFY sip:collector@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP pc22.example.com;branch=z9hG4bK3343d7 Max-Forwards: 70 To: ;tag=43524545 From: Alice ;tag=a3343df32 Call-ID: k3l43id034kevnx7334s CSeq: 4321 NOTIFY Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: rtcp-xr Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Content-Type: text/plain Content-Length: ... Event:rtcp-xr AlertType:rf LocalMetrics:VQMetrics: plm=loss:05 disc:02 burst=den:0 len:0 gap=den:2 len:0 delay=rt:200 es:140 signal=sig: rerl: n: qs=r:82 xr:82 ml:3.4 mc:3.3 DialogID:38419823470834;to-tag=8472761;from-tag=9123dh311 This alert indicates that the quality of the call in progress has degraded to an unacceptable level. In this case, the packet loss rate was 5%, the packet discard rate (due to jitter) was 2%, there were no bursts, the gap loss/discard rate was 2%, the round trip delay was 160mS, the end system delay was 140mS, the R factor was 85, the MOS-LQ 3.6, the MOS-CQ 3.5. In this case, the remote metrics were unavailable and therefore not included. Johnston, et al. Expires August 15, 2004 [Page 10] Internet-Draft RTCP Summary Delivery February 2004 5. Call Flow Examples This section shows a number of call flow examples showing how the event package works. These flows assume that the summary report collector is notified by the registrar when a new User Agent registers which supports the event package. OPEN ISSUE: The ways in which this can be done should probably be discussed in the document. 5.1 End of Session Notification Call Flow Alice Proxy/Registrar Collector Bob | | | | | | | | | REGISTER Allow-Event:rtcp-xr F1 | | |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | | SUBSCRIBE Event:rtcp-xr F3 | | |<-------------------| | | SUBSCRIBE Event:rtcp-xr F4 | | |<-------------------| | | | 200 OK F5 | | | |------------------->| | | | | 200 OK F6 | | | |------------------->| | | INVITE F7 | | | |------------------->| | | | | INVITE F8 | | | |---------------------------------------->| | | 200 OK F9 | | | |<----------------------------------------| | 200 OK F10 | | | |<-------------------| | | | ACK F11 | | | |------------------->| | | | | ACK F12 | | | |---------------------------------------->| | RTP | | | |<============================================================>| | RTCP | | | |<============================================================>| | | | | | BYE F13 | | | |------------------->| BYE F14 | | Johnston, et al. Expires August 15, 2004 [Page 11] Internet-Draft RTCP Summary Delivery February 2004 | |---------------------------------------->| | | 200 OK F15 | | | |<----------------------------------------| | 200 OK F16 | | | |<-------------------| | | | NOTIFY Event:rtcp-xr F17 | | |------------------->| | | | | NOTIFY Event:rtcp-xr F18 | | |------------------->| | | | 200 OK F19 | | | |<-------------------| | | 200 OK F20 | | | |<-------------------| | | Figure 1. Summary report sent after session termination. 5.2 Mid Session Report Alice Proxy/Registrar Collector Bob | | | | | | | | | REGISTER Allow-Event:rtcp-xr F1 | | |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | | SUBSCRIBE Event:rtcp-xr F3 | | |<-------------------| | | SUBSCRIBE Event:rtcp-xr F4 | | |<-------------------| | | | 200 OK F5 | | | |------------------->| | | | | 200 OK F6 | | | |------------------->| | | INVITE F7 | | | |------------------->| | | | | INVITE F8 | | | |---------------------------------------->| | | 200 OK F9 | | | |<----------------------------------------| | 200 OK F10 | | | |<-------------------| | | | ACK F11 | | | |------------------->| | | | | ACK F12 | | | |---------------------------------------->| | RTP | | | |<============================================================>| Johnston, et al. Expires August 15, 2004 [Page 12] Internet-Draft RTCP Summary Delivery February 2004 | RTCP | | | |<============================================================>| | NOTIFY Event:rtcp-xr F17 | | |------------------->| | | | | NOTIFY Event:rtcp-xr F18 | | |------------------->| | | | 200 OK F19 | | | |<-------------------| | | 200 OK F20 | | | |<-------------------| | | | | | | | BYE F13 | | | |------------------->| BYE F14 | | | |---------------------------------------->| | | 200 OK F15 | | | |<----------------------------------------| | 200 OK F16 | | | |<-------------------| | | | NOTIFY Event:rtcp-xr F17 | | |------------------->| | | | | NOTIFY Event:rtcp-xr F18 | | |------------------->| | | | 200 OK F19 | | | |<-------------------| | | 200 OK F20 | | | |<-------------------| | | Figure 2. Summary report sent during session with threshold report. 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 discussions. Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Johnston, et al. Expires August 15, 2004 [Page 13] Internet-Draft RTCP Summary Delivery February 2004 [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 3550, July 2003. [4] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [5] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 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 August 15, 2004 [Page 14] Internet-Draft RTCP Summary Delivery February 2004 Amy Pendleton Nortel Networks 2380 Performance Drive Richardson, TX 75081 EMail: aspen@nortelnetworks.com Johnston, et al. Expires August 15, 2004 [Page 15] Internet-Draft RTCP Summary Delivery February 2004 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 (2004). 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 August 15, 2004 [Page 16] Internet-Draft RTCP Summary Delivery February 2004 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 August 15, 2004 [Page 17]