| < draft-ietf-sipping-rtcp-summary-12.txt | draft-ietf-sipping-rtcp-summary-13.txt > | |||
|---|---|---|---|---|
| SIPPING WG A. Pendleton | SIPPING WG A. Pendleton | |||
| Internet-Draft A. Clark | Internet-Draft A. Clark | |||
| Intended status: Standards Track Telchemy Incorporated | Intended status: Standards Track Telchemy Incorporated | |||
| Expires: January 3, 2011 A. Johnston | Expires: February 5, 2011 A. Johnston | |||
| Avaya | Avaya | |||
| H. Sinnreich | H. Sinnreich | |||
| Unaffiliated | Unaffiliated | |||
| July 2, 2010 | August 4, 2010 | |||
| Session Initiation Protocol Event Package for Voice Quality Reporting | Session Initiation Protocol Event Package for Voice Quality Reporting | |||
| draft-ietf-sipping-rtcp-summary-12 | draft-ietf-sipping-rtcp-summary-13 | |||
| Abstract | Abstract | |||
| This document defines a Session Initiation Protocol (SIP) event | This document defines a Session Initiation Protocol (SIP) event | |||
| package that enables the collection and reporting of metrics that | package that enables the collection and reporting of metrics that | |||
| measure the quality for Voice over Internet Protocol (VoIP) sessions. | measure the quality for Voice over Internet Protocol (VoIP) sessions. | |||
| Voice call quality information derived from RTP Control Protocol | Voice call quality information derived from RTP Control Protocol | |||
| Extended Reports (RTCP-XR) and call information from SIP is conveyed | Extended Reports (RTCP-XR) and call information from SIP is conveyed | |||
| from a User Agent (UA) in a session, known as a reporter, to a third | from a User Agent (UA) in a session, known as a reporter, to a third | |||
| party, known as a collector. A registration for the application/ | party, known as a collector. A registration for the application/ | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| 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 January 3, 2011. | This Internet-Draft will expire on February 5, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 3, line 23 ¶ | skipping to change at page 3, line 23 ¶ | |||
| 3.2. PUBLISH Method . . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. PUBLISH Method . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.3. Multi-Party and Multi-Segment Calls . . . . . . . . . . . 7 | 3.3. Multi-Party and Multi-Segment Calls . . . . . . . . . . . 7 | |||
| 3.4. Overload Avoidance . . . . . . . . . . . . . . . . . . . . 7 | 3.4. Overload Avoidance . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. Event Package Formal Definition . . . . . . . . . . . . . . . 8 | 4. Event Package Formal Definition . . . . . . . . . . . . . . . 8 | |||
| 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 8 | 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 8 | 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 8 | |||
| 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 8 | 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.4. Subscribe Duration . . . . . . . . . . . . . . . . . . . . 8 | 4.4. Subscribe Duration . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8 | 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.6. Voice Quality Event and Semantics . . . . . . . . . . . . 9 | 4.6. Voice Quality Event and Semantics . . . . . . . . . . . . 9 | |||
| 4.6.1. ABNF Syntax Definition . . . . . . . . . . . . . . . . 9 | 4.6.1. ABNF Syntax Definition . . . . . . . . . . . . . . . . 10 | |||
| 4.6.2. Parameter Definitions and Mappings . . . . . . . . . . 20 | 4.6.2. Parameter Definitions and Mappings . . . . . . . . . . 20 | |||
| 4.7. Message Flow and Syntax Examples . . . . . . . . . . . . . 28 | 4.7. Message Flow and Syntax Examples . . . . . . . . . . . . . 28 | |||
| 4.7.1. End of Session Report using NOTIFY . . . . . . . . . . 28 | 4.7.1. End of Session Report using NOTIFY . . . . . . . . . . 29 | |||
| 4.7.2. Mid Session Threshold Violation using NOTIFY . . . . . 30 | 4.7.2. Mid Session Threshold Violation using NOTIFY . . . . . 31 | |||
| 4.7.3. End of Session Report using PUBLISH . . . . . . . . . 33 | 4.7.3. End of Session Report using PUBLISH . . . . . . . . . 33 | |||
| 4.7.4. Alert Report using PUBLISH . . . . . . . . . . . . . . 35 | 4.7.4. Alert Report using PUBLISH . . . . . . . . . . . . . . 35 | |||
| 4.8. Configuration Dataset for vq-rtcpxr Events . . . . . . . . 37 | 4.8. Configuration Dataset for vq-rtcpxr Events . . . . . . . . 37 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 5.1. SIP Event Package Registration . . . . . . . . . . . . . . 37 | 5.1. SIP Event Package Registration . . . . . . . . . . . . . . 37 | |||
| 5.2. application/vq-rtcp-xr MIME Registration . . . . . . . . . 38 | 5.2. application/vq-rtcp-xr MIME Registration . . . . . . . . . 38 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
| 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 39 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 39 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 40 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 39 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
| 1. Introduction | 1. Introduction | |||
| Real time communications over IP networks use SIP for signaling with | Real time communications over IP networks use SIP for signaling with | |||
| RTP/RTCP for media transport and reporting respectively. These | RTP/RTCP for media transport and reporting respectively. These | |||
| protocols are very flexible and can support an extremely wide | protocols are very flexible and can support an extremely wide | |||
| spectrum of usage scenarios. For this reason, extensions to these | spectrum of usage scenarios. For this reason, extensions to these | |||
| protocols must be specified in the context of a specific usage | protocols must be specified in the context of a specific usage | |||
| scenario. In this memo, extensions to SIP are proposed to support | scenario. In this memo, extensions to SIP are proposed to support | |||
| the reporting of RTP Control Protocol Extended Reports [4] metrics. | the reporting of RTP Control Protocol Extended Reports [4] metrics. | |||
| 1.1. Applicability Statement | 1.1. Applicability Statement | |||
| RTP is utilized in many different architectures and topologies. RFC | RTP is utilized in many different architectures and topologies. RFC | |||
| 5117 [15] lists and describes the following topologies: point to | 5117 [13] lists and describes the following topologies: point to | |||
| point, point to multipoint using multicast, point to multipoint using | point, point to multipoint using multicast, point to multipoint using | |||
| the RFC 3550 translator, point to multipoint using the RFC 3550 mixer | the RFC 3550 translator, point to multipoint using the RFC 3550 mixer | |||
| model, point to multipoint using video switching MCUs, point to | model, point to multipoint using video switching MCUs, point to | |||
| multipoint using RTCP-terminating MCU, and non-symmetric mixer/ | multipoint using RTCP-terminating MCU, and non-symmetric mixer/ | |||
| translators. As the abstract to this document points out, this | translators. As the abstract to this document points out, this | |||
| specification is for reporting quality of Voice over Internet | specification is for reporting quality of Voice over Internet | |||
| Protocol(VoIP) sessions. As such, only the first topology, point to | Protocol(VoIP) sessions. As such, only the first topology, point to | |||
| point, is currently supported by this specification. This reflects | point, is currently supported by this specification. This reflects | |||
| both current VoIP deployments which are predominantly point to point | both current VoIP deployments which are predominantly point to point | |||
| using unicast, and also the state of research in the area of quality. | using unicast, and also the state of research in the area of quality. | |||
| skipping to change at page 6, line 4 ¶ | skipping to change at page 6, line 4 ¶ | |||
| The event package supports reporting both the voice quality metrics | The event package supports reporting both the voice quality metrics | |||
| for both inbound and outbound directions. Voice quality metrics for | for both inbound and outbound directions. Voice quality metrics for | |||
| the inbound direction can generally be computed locally by the | the inbound direction can generally be computed locally by the | |||
| reporting endpoint however voice quality metrics for the outbound | reporting endpoint however voice quality metrics for the outbound | |||
| direction are computed by the remote endpoint and sent to the | direction are computed by the remote endpoint and sent to the | |||
| reporting endpoint using the RTCP Extended Reports [4]. | reporting endpoint using the RTCP Extended Reports [4]. | |||
| Configuration of usage of the event package is not covered in this | Configuration of usage of the event package is not covered in this | |||
| document. It is the recommendation of this document that the SIP | document. It is the recommendation of this document that the SIP | |||
| configuration framework [9] be used. This is discussed in Section | configuration framework [15] be used. This is discussed in Section | |||
| 4.8. | 4.8. | |||
| The event package SHOULD be used with the SUBSCRIBE/NOTIFY method | The event package SHOULD be used with the SUBSCRIBE/NOTIFY method | |||
| however it MAY be also used with the PUBLISH method [8] for backward | however it MAY be also used with the PUBLISH method [8] for backward | |||
| compatibility with some existing implementations. Message flow | compatibility with some existing implementations. Message flow | |||
| examples for both methods are provided in this document. | examples for both methods are provided in this document. | |||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| skipping to change at page 6, line 47 ¶ | skipping to change at page 6, line 47 ¶ | |||
| quality metric reports using the NOTIFY method. The REPORTER MUST | quality metric reports using the NOTIFY method. The REPORTER MUST | |||
| NOT send any vq-rtcpxr events if a COLLECTOR address has not been | NOT send any vq-rtcpxr events if a COLLECTOR address has not been | |||
| configured. The REPORTER populates the Request-URI according to the | configured. The REPORTER populates the Request-URI according to the | |||
| rules for an in-dialog request. The COLLECTOR MAY send a SUBSCRIBE | rules for an in-dialog request. The COLLECTOR MAY send a SUBSCRIBE | |||
| to a SIP Proxy acting on behalf of the reporting SIP UA's. | to a SIP Proxy acting on behalf of the reporting SIP UA's. | |||
| 3.2. PUBLISH Method | 3.2. PUBLISH Method | |||
| A SIP UA that supports this specification MAY also send the service | A SIP UA that supports this specification MAY also send the service | |||
| quality metric reports using the PUBLISH method [8], however this | quality metric reports using the PUBLISH method [8], however this | |||
| approach SHOULD NOT be used in unmanaged Internet services. The | approach SHOULD NOT be used in general on the public Internet. The | |||
| PUBLISH method MAY be supported for backward compatibility with | PUBLISH method MAY be supported for backward compatibility with | |||
| existing implementations. | existing implementations. | |||
| The REPORTER MAY therefore populate the Request-URI of the PUBLISH | The REPORTER MAY therefore populate the Request-URI of the PUBLISH | |||
| method with the address of the COLLECTOR. To ensure security of SIP | method with the address of the COLLECTOR. To ensure security of SIP | |||
| proxies and the COLLECTOR, the REPORTER MUST be configured with the | proxies and the COLLECTOR, the REPORTER MUST be configured with the | |||
| address of the COLLECTOR, preferably using the SIP UA configuration | address of the COLLECTOR, preferably using the SIP UA configuration | |||
| framework [9], as described in section 5.8. | framework [15], as described in section 5.8. | |||
| It is recommended that the REPORTER send an OPTIONS message to the | It is RECOMMENDED that the REPORTER send an OPTIONS message to the | |||
| COLLECTOR to ensure support of the PUBLISH message. | COLLECTOR to ensure support of the PUBLISH message. | |||
| If PUBLISH is not supported, then the reporter can only wait for a | ||||
| SUBSCRIBE request from the collector and then deliver the | ||||
| information in NOTIFYs. If a REPORTER sends a PUBLISH to a | ||||
| COLLECTOR that does not support or allow this method, a 501 Not | ||||
| Implemented or a 405 Method Not Allowed response will be received, | ||||
| and the REPORTER will stop publication. | ||||
| 3.3. Multi-Party and Multi-Segment Calls | 3.3. Multi-Party and Multi-Segment Calls | |||
| A voice quality metric report may be sent for each session | A voice quality metric report may be sent for each session | |||
| terminating at the REPORTER and may contain multiple report bodies. | terminating at the REPORTER and may contain multiple report bodies. | |||
| For a multi-party call the report MAY contain report bodies for the | For a multi-party call the report MAY contain report bodies for the | |||
| session between the reporting endpoint and each remote endpoint for | session between the reporting endpoint and each remote endpoint for | |||
| which there was an RTP session during the call. | which there was an RTP session during the call. | |||
| Multi-party services such as call hold and call transfer can result | Multi-party services such as call hold and call transfer can result | |||
| in the user participating in a series of concatenated sessions, | in the user participating in a series of concatenated sessions, | |||
| potentially with different choices of codec or sample rate, although | potentially with different choices of codec or sample rate, although | |||
| these may be perceived by the user as a single call. A REPORTER MAY | these may be perceived by the user as a single call. A REPORTER MAY | |||
| send a voice quality metric report at the end of each session or MAY | send a voice quality metric report at the end of each session or MAY | |||
| send a single voice quality metric report containing a report body | send a single voice quality metric report containing an application/ | |||
| for each segment of the call. | vq-rtcp-xr body for each segment of the call. | |||
| 3.4. Overload Avoidance | 3.4. Overload Avoidance | |||
| Users of this extension should ensure they implement general SIP | Users of this extension should ensure they implement general SIP | |||
| mechanisms for avoiding overload. For instance, an overloaded proxy | mechanisms for avoiding overload. For instance, an overloaded proxy | |||
| or COLLECTOR MUST send a 503 Service Unavailable or other 5xx esponse | or COLLECTOR MUST send a 503 Service Unavailable or other 5xx | |||
| with an appropriate Retry-After time specified. REPORTERs MUST act | response with an appropriate Retry-After time specified. REPORTERs | |||
| on these responses and respect the retry after time interval. In | MUST act on these responses and respect the Retry-After time | |||
| addition, future SIP extensions to better handle overload as covered | interval. In addition, future SIP extensions to better handle | |||
| in [16] should be followed as they are standardized. | overload as covered in [14] should be followed as they are | |||
| standardized. | ||||
| To avoid overload of SIP Proxies or COLLECTORS it is important to do | To avoid overload of SIP Proxies or COLLECTORS it is important to do | |||
| capacity planning and to minimize the number of reports that are | capacity planning and to minimize the number of reports that are | |||
| sent. | sent. | |||
| Approaches to avoiding overload include: | Approaches to avoiding overload include: | |||
| a. Send only one report at the end of each call | a. Send only one report at the end of each call | |||
| b. Use interval reports only on "problem" calls that are being | b. Use interval reports only on "problem" calls that are being | |||
| skipping to change at page 9, line 18 ¶ | skipping to change at page 9, line 27 ¶ | |||
| represent those values as received by the REPORTER. In some | represent those values as received by the REPORTER. In some | |||
| scenarios, these may not be the same on either end of the session - | scenarios, these may not be the same on either end of the session - | |||
| the COLLECTOR will need logic to be able to put these sessions | the COLLECTOR will need logic to be able to put these sessions | |||
| together. The values of parameters such as sample rate, frame | together. The values of parameters such as sample rate, frame | |||
| duration, frame octets, packets per second, round trip delay, etc | duration, frame octets, packets per second, round trip delay, etc | |||
| depend on the type of report they are present in. If present in a | depend on the type of report they are present in. If present in a | |||
| Session or an Interval report, they represent average values over the | Session or an Interval report, they represent average values over the | |||
| session or interval. If present in an Alert report, they represent | session or interval. If present in an Alert report, they represent | |||
| instantaneous values. | instantaneous values. | |||
| The REPORTER always shares local quality reporting information and | The REPORTER always includes local quality reporting information and | |||
| should, if possible, share remote quality reporting information. | should, if possible, share remote quality reporting information to | |||
| This remote quality could be available from received RTCP-XR reports | the COLLECTOR. This remote quality could be available from received | |||
| or other sources. Reporting this is useful in cases where the other | RTCP-XR reports or other sources. Reporting this is useful in cases | |||
| end might support RTCP-XR but not this voice quality reporting. | where the other end might support RTCP-XR but not this voice quality | |||
| reporting. | ||||
| This specification defines a new MIME type application/vq-rtcpxr | This specification defines a new MIME type application/vq-rtcpxr | |||
| which is a text encoding of the RTCP and RTCP-XR statistics with some | which is a text encoding of the RTCP and RTCP-XR statistics with some | |||
| additional metrics and correlation information. | additional metrics and correlation information. | |||
| 4.6. Voice Quality Event and Semantics | 4.6. Voice Quality Event and Semantics | |||
| This section describes the syntax extensions required for event | This section describes the syntax extensions required for event | |||
| publication in SIP. The formal syntax definitions described in this | publication in SIP. The formal syntax definitions described in this | |||
| section are expressed in the Augmented BNF [6] format used in SIP | section are expressed in the Augmented BNF [6] format used in SIP | |||
| skipping to change at page 15, line 51 ¶ | skipping to change at page 16, line 13 ¶ | |||
| *(WSP Extension) | *(WSP Extension) | |||
| ; RoundTripDelay SHALL be measured as defined in RFC3550 [3]. | ; RoundTripDelay SHALL be measured as defined in RFC3550 [3]. | |||
| RoundTripDelay = "RTD" EQUAL (1*5DIGIT) ;0-65535 | RoundTripDelay = "RTD" EQUAL (1*5DIGIT) ;0-65535 | |||
| ; EndSystemDelay metric is defined in RFC 3611 [4] | ; EndSystemDelay metric is defined in RFC 3611 [4] | |||
| EndSystemDelay = "ESD" EQUAL (1*5DIGIT) ;0-65535 | EndSystemDelay = "ESD" EQUAL (1*5DIGIT) ;0-65535 | |||
| ; OneWayDelay is defined in RFC 2679 [14] | ; OneWayDelay is defined in RFC 2679 [12] | |||
| OneWayDelay = "OWD" EQUAL (1*5DIGIT) ;0-65535 | OneWayDelay = "OWD" EQUAL (1*5DIGIT) ;0-65535 | |||
| ; SymmOneWayDelay is defined as half the sum of RoundTripDelay | ; SymmOneWayDelay is defined as half the sum of RoundTripDelay | |||
| ; and the EndSystemDelay values for both endpoints. | ; and the EndSystemDelay values for both endpoints. | |||
| SymmOneWayDelay = "SOWD" EQUAL (1*5DIGIT); 0-65535 | SymmOneWayDelay = "SOWD" EQUAL (1*5DIGIT); 0-65535 | |||
| ; Interarrival Jitter is calculated as defined RFC 3550 | ; Interarrival Jitter is calculated as defined RFC 3550 | |||
| ; and converted into milliseconds | ; and converted into milliseconds | |||
| InterarrivalJitter = "IAJ" EQUAL (1*5DIGIT) ;0-65535 ms | InterarrivalJitter = "IAJ" EQUAL (1*5DIGIT) ;0-65535 ms | |||
| ; Mean Absolute Jitter is measured as defined | ; Mean Absolute Jitter is measured as defined | |||
| ; by ITU-T G.1020 [11] where it is known as MAPDV | ; by ITU-T G.1020 [9] where it is known as MAPDV | |||
| MeanAbsoluteJitter = "MAJ" EQUAL (1*5DIGIT);0-65535 | MeanAbsoluteJitter = "MAJ" EQUAL (1*5DIGIT);0-65535 | |||
| ; Signal metrics definitions are provided in RFC 3611 | ; Signal metrics definitions are provided in RFC 3611 | |||
| Signal = "Signal" HCOLON | Signal = "Signal" HCOLON | |||
| [ SignalLevel WSP ] | [ SignalLevel WSP ] | |||
| [ NoiseLevel WSP ] | [ NoiseLevel WSP ] | |||
| [ ResidualEchoReturnLoss ] | [ ResidualEchoReturnLoss ] | |||
| *(WSP Extension) | *(WSP Extension) | |||
| skipping to change at page 17, line 40 ¶ | skipping to change at page 17, line 49 ¶ | |||
| [ ExtROutEstAlg WSP ] | [ ExtROutEstAlg WSP ] | |||
| [ MOS-LQ WSP ] | [ MOS-LQ WSP ] | |||
| [ MOSLQEstAlg WSP ] | [ MOSLQEstAlg WSP ] | |||
| [ MOS-CQ WSP ] | [ MOS-CQ WSP ] | |||
| [ MOSCQEstAlg WSP ] | [ MOSCQEstAlg WSP ] | |||
| [ QoEEstAlg ] | [ QoEEstAlg ] | |||
| *(WSP Extension) | *(WSP Extension) | |||
| ListeningQualityR = "RLQ" EQUAL (1*3DIGIT) ; 0 - 120 | ListeningQualityR = "RLQ" EQUAL (1*3DIGIT) ; 0 - 120 | |||
| RLQEstAlg = "RLQEstAlg" EQUAL word ; "P.564" [12], or other | RLQEstAlg = "RLQEstAlg" EQUAL word ; "P.564" [10], or other | |||
| ConversationalQualityR = "RCQ" EQUAL (1*3DIGIT) ; 0 - 120 | ConversationalQualityR = "RCQ" EQUAL (1*3DIGIT) ; 0 - 120 | |||
| RCQEstAlg = "RCQEstAlg" EQUAL word ; "P.564", or other | RCQEstAlg = "RCQEstAlg" EQUAL word ; "P.564", or other | |||
| ; ExternalR-In is measured by the local endpoint for incoming | ; ExternalR-In is measured by the local endpoint for incoming | |||
| ; connection on "other" side of this endpoint | ; connection on "other" side of this endpoint | |||
| ; e.g. Phone A <---> Bridge <----> Phone B | ; e.g. Phone A <---> Bridge <----> Phone B | |||
| ; ListeningQualityR = quality for Phone A ----> Bridge path | ; ListeningQualityR = quality for Phone A ----> Bridge path | |||
| ; ExternalR-In = quality for Bridge <---- Phone B path | ; ExternalR-In = quality for Bridge <---- Phone B path | |||
| ExternalR-In = "EXTRI" EQUAL (1*3DIGIT) ; 0 - 120 | ExternalR-In = "EXTRI" EQUAL (1*3DIGIT) ; 0 - 120 | |||
| ExtRInEstAlg = "ExtRIEstAlg" EQUAL word ; "P.564" or other | ExtRInEstAlg = "ExtRIEstAlg" EQUAL word ; "P.564" or other | |||
| ; ExternalR-Out is copied from RTCP XR message received from the | ; ExternalR-Out is copied from RTCP XR message received from the | |||
| ; remote endpoint on "other" side of this endpoint | ; remote endpoint on "other" side of this endpoint | |||
| ; e.g. Phone A <---> Bridge <----> Phone B | ; e.g. Phone A <---> Bridge <----> Phone B | |||
| ; ExternalR-Out = quality for Bridge -----> Phone B path | ; ExternalR-Out = quality for Bridge -----> Phone B path | |||
| ExternalR-Out = "EXTRO" EQUAL (1*3DIGIT) ; 0 - 120 | ExternalR-Out = "EXTRO" EQUAL (1*3DIGIT) ; 0 - 120 | |||
| ExtROutEstAlg = "ExtROEstAlg" EQUAL word ; "P.564" or other | ExtROutEstAlg = "ExtROEstAlg" EQUAL word ; "P.564" or other | |||
| skipping to change at page 22, line 41 ¶ | skipping to change at page 23, line 7 ¶ | |||
| This parameter is not contained in RTP or SDP but can usually be | This parameter is not contained in RTP or SDP but can usually be | |||
| obtained from the device codec. This field provides the number of | obtained from the device codec. This field provides the number of | |||
| frames in each RTP packet. Note this value can be combined with the | frames in each RTP packet. Note this value can be combined with the | |||
| FrameDuration to determine the packetization rate. Also, where a | FrameDuration to determine the packetization rate. Also, where a | |||
| sample-based codec is used, a "frame" refers to the set of samples | sample-based codec is used, a "frame" refers to the set of samples | |||
| carried in an RTP packet. | carried in an RTP packet. | |||
| 4.6.2.3.8. FMTP Options | 4.6.2.3.8. FMTP Options | |||
| This parameter is taken directly from the SDP attribute "fmtp". | This parameter is taken directly from the SDP attribute "fmtp" | |||
| defined in RFC4566. | ||||
| 4.6.2.3.9. Silence Suppression State | 4.6.2.3.9. Silence Suppression State | |||
| This parameter does not correspond to SDP, RTP, or RTCP XR. It | This parameter does not correspond to SDP, RTP, or RTCP XR. It | |||
| indicates whether silence suppression, also known as Voice Activity | indicates whether silence suppression, also known as Voice Activity | |||
| Detection (VAD) is enabled for the identified session. | Detection (VAD) is enabled for the identified session. | |||
| 4.6.2.3.10. Packet Loss Concealment | 4.6.2.3.10. Packet Loss Concealment | |||
| This value corresponds to "PLC" in RFC3611 in the VoIP Metrics Report | This value corresponds to "PLC" in RFC3611 in the VoIP Metrics Report | |||
| Block. The values defined by RFC3611 are reused by this | Block. The values defined by RFC3611 are reused by this | |||
| recommendation and therefore no mapping is required. | recommendation and therefore no mapping is required. | |||
| 4.6.2.4. LocalAddr | 4.6.2.4. LocalAddr | |||
| This field provides the IP address, port and synchronization source | This field provides the IP address, port and synchronization source | |||
| (SSRC) for the session from the perspective of the endpoint that is | (SSRC) for the session from the perspective of the endpoint that is | |||
| measuring performance. The IPAddress can be IPv4 or IPv6 format. | measuring performance. The IPAddress MAY be IPv4 or IPv6 format. | |||
| The SSRC is taken from SDP, RTCP, or RTCP XR input parameters. | The SSRC is taken from SDP, RTCP, or RTCP XR input parameters. | |||
| In the presence of NAT and where a NAT-traversal mechanism such as | In the presence of NAT and where a NAT-traversal mechanism such as | |||
| STUN [10] is used, the external IP address can be reported, since the | STUN [16] is used, the external IP address can be reported, since the | |||
| internal IP address is not visible to the network operator. | internal IP address is not visible to the network operator. | |||
| 4.6.2.5. RemoteAddr | 4.6.2.5. RemoteAddr | |||
| This field provides the IP address, port and ssrc of the session peer | This field provides the IP address, port and ssrc of the session peer | |||
| from the perspective of the remote endpoint measuring performance. | from the perspective of the remote endpoint measuring performance. | |||
| In the presence of NAT and where a NAT-traversal mechanism such as | In the presence of NAT and where a NAT-traversal mechanism such as | |||
| STUN [10] is used, the external IP address can be reported, since the | STUN [16] is used, the external IP address can be reported, since the | |||
| internal IP address is not visible to the network operator. | internal IP address is not visible to the network operator. | |||
| 4.6.2.6. Jitter Buffer Parameters | 4.6.2.6. Jitter Buffer Parameters | |||
| 4.6.2.6.1. Jitter Buffer Adaptive | 4.6.2.6.1. Jitter Buffer Adaptive | |||
| This value corresponds to "JBA" in RFC3611 in the VoIP Metrics Report | This value corresponds to "JBA" in RFC3611 in the VoIP Metrics Report | |||
| Block. The values defined by RFC3611 are unchanged and therefore no | Block. The values defined by RFC3611 are unchanged and therefore no | |||
| mapping is required. | mapping is required. | |||
| skipping to change at page 25, line 4 ¶ | skipping to change at page 25, line 18 ¶ | |||
| Metrics Report Block. This value requires no conversion; the exact | Metrics Report Block. This value requires no conversion; the exact | |||
| value sent in an RTCP XR VoIP Metrics Report Block can be reported. | value sent in an RTCP XR VoIP Metrics Report Block can be reported. | |||
| 4.6.2.8.5. Minimum Gap Threshold | 4.6.2.8.5. Minimum Gap Threshold | |||
| This value corresponds to "Gmin" in RFC3611 in the VoIP Metrics | This value corresponds to "Gmin" in RFC3611 in the VoIP Metrics | |||
| Report Block. This value requires no conversion; the exact value | Report Block. This value requires no conversion; the exact value | |||
| sent in an RTCP XR VoIP Metrics Report Block can be reported. | sent in an RTCP XR VoIP Metrics Report Block can be reported. | |||
| 4.6.2.9. Delay Parameters | 4.6.2.9. Delay Parameters | |||
| 4.6.2.9.1. Round Trip Delay | 4.6.2.9.1. Round Trip Delay | |||
| This value corresponds to "round trip delay" in RFC3611 in the VoIP | This value corresponds to "round trip delay" in RFC3611 in the VoIP | |||
| Metrics Report Block and may be measured using the method defined in | Metrics Report Block and may be measured using the method defined in | |||
| RFC3550. The parameter is expressed in milliseconds. | RFC3550. The parameter is expressed in milliseconds. | |||
| 4.6.2.9.2. End System Delay | 4.6.2.9.2. End System Delay | |||
| This value corresponds to "end system delay" in RFC3611 in the VoIP | This value corresponds to "end system delay" in RFC3611 in the VoIP | |||
| Metrics Report Block. This parameter does not require any | Metrics Report Block. This parameter does not require any | |||
| conversion. The parameter is expressed in milliseconds. | conversion. The parameter is expressed in milliseconds. | |||
| 4.6.2.9.3. Symmetric One Way Delay | 4.6.2.9.3. Symmetric One Way Delay | |||
| This value is computed by adding Round Trip Delay to the local and | This value is computed by adding Round Trip Delay to the local and | |||
| remote End System Delay and dividing by two. | remote End System Delay and dividing by two. | |||
| 4.6.2.9.4. One Way Delay | 4.6.2.9.4. One Way Delay | |||
| This value SHOULD be measured using the methods defined in IETF RFC | This value SHOULD be measured using the methods defined in IETF RFC | |||
| 2679 [14]. The parameter is expressed in milliseconds. | 2679 [12]. The parameter is expressed in milliseconds. | |||
| 4.6.2.9.5. Inter-arrival Jitter | 4.6.2.9.5. Inter-arrival Jitter | |||
| Inter-arrival jitter is calculated as defined in RFC 3550 and | Inter-arrival jitter is calculated as defined in RFC 3550 and | |||
| converted into milliseconds. | converted into milliseconds. | |||
| 4.6.2.9.6. Mean Absolute Jitter | 4.6.2.9.6. Mean Absolute Jitter | |||
| It is recommended that MAJ be measured as defined in ITU-T G.1020 | It is recommended that MAJ be measured as defined in ITU-T G.1020 | |||
| [11]. This parameter is often referred to as MAPDV. The parameter | [9]. This parameter is often referred to as MAPDV. The parameter is | |||
| is expressed in milliseconds. | expressed in milliseconds. | |||
| 4.6.2.10. Signal-related Parameters | 4.6.2.10. Signal-related Parameters | |||
| 4.6.2.10.1. Signal Level | 4.6.2.10.1. Signal Level | |||
| This field corresponds to "signal level" in RFC3611 in the VoIP | This field corresponds to "signal level" in RFC3611 in the VoIP | |||
| Metrics Report Block. This field provides the voice signal relative | Metrics Report Block. This field provides the voice signal relative | |||
| level is defined as the ratio of the signal level to a 0 dBm0 | level is defined as the ratio of the signal level to a 0 dBm0 | |||
| reference, expressed in decibels. This value can be used directly | reference, expressed in decibels. This value can be used directly | |||
| without extra conversion. | without extra conversion. | |||
| skipping to change at page 26, line 22 ¶ | skipping to change at page 26, line 38 ¶ | |||
| directly without extra conversion. | directly without extra conversion. | |||
| 4.6.2.11. Quality Scores | 4.6.2.11. Quality Scores | |||
| 4.6.2.11.1. ListeningQualityR | 4.6.2.11.1. ListeningQualityR | |||
| This field reports the listening quality expressed as an R factor | This field reports the listening quality expressed as an R factor | |||
| (per G.107). This does not include the effects of echo or delay. | (per G.107). This does not include the effects of echo or delay. | |||
| The range of R is 0-95 for narrowband calls and 0-120 for wideband | The range of R is 0-95 for narrowband calls and 0-120 for wideband | |||
| calls. Algorithms for computing this value SHOULD be compliant with | calls. Algorithms for computing this value SHOULD be compliant with | |||
| ITU-T Recommendations P.564 [12] and G.107 [13]. | ITU-T Recommendations P.564 [10] and G.107 [11]. | |||
| 4.6.2.11.2. RLQEstAlg | 4.6.2.11.2. RLQEstAlg | |||
| This field provides a text name for the algorithm used to estimate | This field provides a text name for the algorithm used to estimate | |||
| ListeningQualityR. This field will be free form text and not | ListeningQualityR. This field will be free form text and not | |||
| necessarily reflective of any standards or recommendations. | necessarily reflective of any standards or recommendations. | |||
| 4.6.2.11.3. ConversationalQualityR | 4.6.2.11.3. ConversationalQualityR | |||
| This field corresponds to "R factor" in RFC3611 in the VoIP Metrics | This field corresponds to "R factor" in RFC3611 in the VoIP Metrics | |||
| skipping to change at page 28, line 5 ¶ | skipping to change at page 28, line 20 ¶ | |||
| MOS-xQ parameter if the RFC3611 reported value is 127 (which | MOS-xQ parameter if the RFC3611 reported value is 127 (which | |||
| indicates unavailable). | indicates unavailable). | |||
| 4.6.2.11.9.1. MOS-LQ | 4.6.2.11.9.1. MOS-LQ | |||
| This field corresponds to "MOSLQ" in RFC3611 in the VoIP Metrics | This field corresponds to "MOSLQ" in RFC3611 in the VoIP Metrics | |||
| Report Block. This parameter is the estimated mean opinion score for | Report Block. This parameter is the estimated mean opinion score for | |||
| listening voice quality on a scale from 1 to 5, in which 5 represents | listening voice quality on a scale from 1 to 5, in which 5 represents | |||
| "Excellent" and 1 represents "Unacceptable". Algorithms for | "Excellent" and 1 represents "Unacceptable". Algorithms for | |||
| computing this value SHOULD be compliant with ITU-T Recommendation | computing this value SHOULD be compliant with ITU-T Recommendation | |||
| P.564 [12]. This field provides a text name for the algorithm used | P.564 [10]. This field provides a text name for the algorithm used | |||
| to estimate MOS-LQ. | to estimate MOS-LQ. | |||
| 4.6.2.11.9.2. MOS-CQ | 4.6.2.11.9.2. MOS-CQ | |||
| This field corresponds to "MOSCQ" in RFC3611 in the VoIP Metrics | This field corresponds to "MOSCQ" in RFC3611 in the VoIP Metrics | |||
| Report Block. This parameter is the estimated mean opinion score for | Report Block. This parameter is the estimated mean opinion score for | |||
| conversation voice quality on a scale from 1 to 5, in which 5 | conversation voice quality on a scale from 1 to 5, in which 5 | |||
| represents excellent and 1 represents unacceptable. Algorithms for | represents excellent and 1 represents unacceptable. Algorithms for | |||
| computing this value SHOULD be compliant with ITU-T Recommendation | computing this value SHOULD be compliant with ITU-T Recommendation | |||
| P.564 with regard to the listening quality element of the computed | P.564 with regard to the listening quality element of the computed | |||
| skipping to change at page 30, line 15 ¶ | skipping to change at page 30, line 29 ¶ | |||
| SUBSCRIBE, NOTIFY | SUBSCRIBE, NOTIFY | |||
| Event: vq-rtcpxr | Event: vq-rtcpxr | |||
| Accept: application/sdp, message/sipfrag | Accept: application/sdp, message/sipfrag | |||
| Subscription-State: active;expires=3600 | Subscription-State: active;expires=3600 | |||
| Content-Type: application/vq-rtcpxr | Content-Type: application/vq-rtcpxr | |||
| Content-Length: ... | Content-Length: ... | |||
| VQSessionReport: CallTerm | VQSessionReport: CallTerm | |||
| CallID: 6dg37f1890463 | CallID: 6dg37f1890463 | |||
| LocalID: Alice <sip:alice@example.org> | LocalID: Alice <sip:alice@example.org> | |||
| RemoteID: Bill <sip:bill@elpmaxe.org> | RemoteID: Bill <sip:bill@example.net> | |||
| OrigID: Alice <sip:alice@example.org> | OrigID: Alice <sip:alice@example.org> | |||
| LocalGroup: example-phone-55671 | LocalGroup: example-phone-55671 | |||
| RemoteGroup: example-gateway-09871 | RemoteGroup: example-gateway-09871 | |||
| LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d | LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d | |||
| LocalMAC: 00:1f:5b:cc:21:0f | LocalMAC: 00:1f:5b:cc:21:0f | |||
| RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd | RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd | |||
| RemoteMAC: 00:26:08:8e:95:02 | RemoteMAC: 00:26:08:8e:95:02 | |||
| LocalMetrics: | LocalMetrics: | |||
| Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z | Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z | |||
| SessionDesc:PT=0 PD=PCMU SR=8000 FD=20 FO=160 FPP=1 PPS=50 | SessionDesc:PT=0 PD=PCMU SR=8000 FD=20 FO=160 FPP=1 PPS=50 | |||
| skipping to change at page 34, line 31 ¶ | skipping to change at page 34, line 45 ¶ | |||
| Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, | Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, | |||
| SUBSCRIBE, NOTIFY | SUBSCRIBE, NOTIFY | |||
| Event: vq-rtcpxr | Event: vq-rtcpxr | |||
| Accept: application/sdp, message/sipfrag | Accept: application/sdp, message/sipfrag | |||
| Content-Type: application/vq-rtcpxr | Content-Type: application/vq-rtcpxr | |||
| Content-Length: ... | Content-Length: ... | |||
| VQSessionReport: CallTerm | VQSessionReport: CallTerm | |||
| CallID: 6dg37f1890463 | CallID: 6dg37f1890463 | |||
| LocalID: Alice <sip:alice@example.org> | LocalID: Alice <sip:alice@example.org> | |||
| RemoteID: Bill <sip:bill@elpmaxe.org> | RemoteID: Bill <sip:bill@example.net> | |||
| OrigID: Alice <sip:alice@example.org> | OrigID: Alice <sip:alice@example.org> | |||
| LocalGroup: example-phone-55671 | LocalGroup: example-phone-55671 | |||
| RemoteGroup: example-gateway-09871 | RemoteGroup: example-gateway-09871 | |||
| LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d | LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d | |||
| LocalMAC: 00:1f:5b:cc:21:0f | LocalMAC: 00:1f:5b:cc:21:0f | |||
| RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd | RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd | |||
| RemoteMAC: 00:26:08:8e:95:02 | RemoteMAC: 00:26:08:8e:95:02 | |||
| LocalMetrics: | LocalMetrics: | |||
| Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z | Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z | |||
| SessionDesc:PT=18 PD=G729 SR=8000 FD=20 FO=20 FPP=2 PPS=50 | SessionDesc:PT=18 PD=G729 SR=8000 FD=20 FO=20 FPP=2 PPS=50 | |||
| skipping to change at page 37, line 15 ¶ | skipping to change at page 37, line 29 ¶ | |||
| Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 | Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 | |||
| Signal:SL=-23 NL=-60 RERL=55 | Signal:SL=-23 NL=-60 RERL=55 | |||
| QualityEst:RLQ=90 RCQ=85 EXTRI=90 MOSLQ=4.2 MOSCQ=4.3 | QualityEst:RLQ=90 RCQ=85 EXTRI=90 MOSLQ=4.2 MOSCQ=4.3 | |||
| QoEEstAlg=P.564 | QoEEstAlg=P.564 | |||
| DialogID:1890463548@alice.example.org;to-tag=8472761; | DialogID:1890463548@alice.example.org;to-tag=8472761; | |||
| from-tag=9123dh3111 | from-tag=9123dh3111 | |||
| 4.8. Configuration Dataset for vq-rtcpxr Events | 4.8. Configuration Dataset for vq-rtcpxr Events | |||
| It is the suggestion of the authors that the SIP configuration | It is the suggestion of the authors that the SIP configuration | |||
| framework [9] be used to establish the necessary parameters for usage | framework [15] be used to establish the necessary parameters for | |||
| of vq-rtcpxr events. A dataset for this purpose should be designed | usage of vq-rtcpxr events. A dataset for this purpose should be | |||
| and documented in a separate draft upon completion of the framework. | designed and documented in a separate draft upon completion of the | |||
| framework. | ||||
| 5. IANA Considerations | 5. IANA Considerations | |||
| This document registers a new SIP Event Package and a new MIME type. | This document registers a new SIP Event Package and a new MIME type. | |||
| 5.1. SIP Event Package Registration | 5.1. SIP Event Package Registration | |||
| Package name: vq-rtcpx | Package name: vq-rtcpx | |||
| Type: package | Type: package | |||
| Contact: Amy Pendleton <aspen@telchemy.com> | Contact: Amy Pendleton <aspen@telchemy.com> | |||
| skipping to change at page 39, line 32 ¶ | skipping to change at page 39, line 32 ¶ | |||
| [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax | [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |||
| Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
| [7] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: | [7] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: | |||
| Timestamps", RFC 3339, July 2002. | Timestamps", RFC 3339, July 2002. | |||
| [8] Niemi, A., "Session Initiation Protocol (SIP) Extension for | [8] Niemi, A., "Session Initiation Protocol (SIP) Extension for | |||
| Event State Publication", RFC 3903, October 2004. | Event State Publication", RFC 3903, October 2004. | |||
| [9] Channabasappa, S., "A Framework for Session Initiation Protocol | [9] ITU-T G.1020, "Performance parameter definitions for quality of | |||
| User Agent Profile Delivery", | ||||
| draft-ietf-sipping-config-framework-17 (work in progress), | ||||
| February 2010. | ||||
| [10] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session | ||||
| Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. | ||||
| [11] ITU-T G.1020, "Performance parameter definitions for quality of | ||||
| speech and other voiceband applications utilizing IP | speech and other voiceband applications utilizing IP | |||
| networks.". | networks.". | |||
| [12] ITU-T P.564, "Conformance testing for voice over IP | [10] ITU-T P.564, "Conformance testing for voice over IP | |||
| transmission quality assessment models.". | transmission quality assessment models.". | |||
| [13] ITU-T G.107, "The E-model, a computational model for use in | [11] ITU-T G.107, "The E-model, a computational model for use in | |||
| transmission planning.". | transmission planning.". | |||
| [14] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay | [12] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay | |||
| Metric for IPPM", RFC 2679, September 1999. | Metric for IPPM", RFC 2679, September 1999. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [15] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, | [13] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, | |||
| January 2008. | January 2008. | |||
| [16] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design | [14] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design | |||
| Considerations for Session Initiation Protocol (SIP) Overload | Considerations for Session Initiation Protocol (SIP) Overload | |||
| Control", draft-ietf-sipping-overload-design-02 (work in | Control", draft-ietf-sipping-overload-design-02 (work in | |||
| progress), July 2009. | progress), July 2009. | |||
| [15] Channabasappa, S., "A Framework for Session Initiation Protocol | ||||
| User Agent Profile Delivery", | ||||
| draft-ietf-sipping-config-framework-17 (work in progress), | ||||
| February 2010. | ||||
| [16] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session | ||||
| Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Amy Pendleton | Amy Pendleton | |||
| Telchemy Incorporated | Telchemy Incorporated | |||
| Email: aspen@telchemy.com | Email: aspen@telchemy.com | |||
| Alan Clark | Alan Clark | |||
| Telchemy Incorporated | Telchemy Incorporated | |||
| End of changes. 40 change blocks. | ||||
| 57 lines changed or deleted | 70 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/ | ||||