One document matched: draft-johnston-sipping-rtcp-summary-03.txt
Differences from draft-johnston-sipping-rtcp-summary-02.txt
SIPPING Working Group A. Johnston
Internet-Draft H. Sinnreich
Expires: January 16, 2005 MCI
A. Clark
Telchemy Incorporated
A. Pendleton
Nortel Networks
July 18, 2004
RTCP Summary Report Delivery to Third Parties
draft-johnston-sipping-rtcp-summary-03
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 January 16, 2005.
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 from VoIP
applications in endpoints to non-participants in the session. A
Johnston, et al. Expires January 16, 2005 [Page 1]
Internet-Draft RTCP Summary Delivery July 2004
publication mechanism using a new SIP events package is proposed as a
solution. An event package "perfrpt" and an application/rtcp-xr MIME
type is defined in this document along with some example call flows.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations for the Approach . . . . . . . . . . . . . . . . . 4
4. Why SNMP is Not Appropriate . . . . . . . . . . . . . . . . . 4
5. SIP Events Approach . . . . . . . . . . . . . . . . . . . . . 4
6. Event Package Formal Definition . . . . . . . . . . . . . . . 5
6.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5
6.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5
6.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5
6.4 Subscription Duration . . . . . . . . . . . . . . . . . . 5
6.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5
6.6 Metric Definitions . . . . . . . . . . . . . . . . . . . . 7
6.7 Use of PUBLISH Method . . . . . . . . . . . . . . . . . . 9
6.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . . 12
7.1 End of Session Notification Call Flow . . . . . . . . . . 12
7.2 Mid Session Report . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1 SIP Event Package Registration . . . . . . . . . . . . . . 14
8.2 application/rtcp-xr MIME Registration . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Updates since -02 . . . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Johnston, et al. Expires January 16, 2005 [Page 2]
Internet-Draft RTCP Summary Delivery July 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 and a mechanism to allow a
third party which is not a participant in a session receive RTCP
summary reports.
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 VoIP application should not have to store large amounts of
information.
REQ-3: The VoIP application must be able to authenticate the third
party.
REQ-4: The RTCP report information must be able to be transferred
securely.
REQ-5: A VoIP application participating in a bi-directional session
will store and send RTCP summary reports for both directions.
Johnston, et al. Expires January 16, 2005 [Page 3]
Internet-Draft RTCP Summary Delivery July 2004
REQ-6: The reports will include or be associated with dialog
identifiers for correlation purposes.
3. Motivations for the Approach
Monitor the application:
While QoS monitoring in network elements using for example SNMP is
quite common, only the VoIP applications in endpoints are close
enough to the experience of individual users, on a call by call basis
in endpoints as diverse as desktop SIP phones, PDAs, PCs or mobile
phones. For this reason, the approach taken here is to monitor the
voice quality at the application level and not in network elements.
Focus on voice specific impairments:
RTCP extensions support the monitoring of various impairments such as
packet loss, delay and jitter, but more important, specific metrics
are included to measure burst errors that produce voice clipping.
Voice clipping is the most annoying impairment in VoIP due to network
congestion in the media path between VoIP applications.
4. Why SNMP is Not Appropriate
Since this type of QoS monitoring seems related to management, SNMP
could possibly be used to collect this type of data as well. SNMP is
however primarily used for management of network devices as they
relate to the infrastructure but is not typically used for management
of applications on that infrastructure. The focus of SIP is
applications and the performance management for those applications
cannot rely on SNMP. SNMP may be used to manage some aspects of the
physical device aspects of the SIP user agent
Specifically, 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.
5. SIP Events Approach
In this approach, a new SIP events package [6] is be defined. The
intended method to use for this event is PUBLISH [8], though it could
Johnston, et al. Expires January 16, 2005 [Page 4]
Internet-Draft RTCP Summary Delivery July 2004
also be used with SUBSCRIBE and NOTIFY. A VoIP application will
PUBLISH performance data to a State Agent which will make the
information available to other applications.
6. Event Package Formal Definition
6.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:
"perfrpt"
6.2 Event Package Parameters
No event package parameters are defined.
6.3 SUBSCRIBE Bodies
No SUBSCRIBE bodies are described by this specification.
6.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.
6.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.
This specification defines a new MIME type application/rtcp-xr which
is a text encoding of the RTCP-XR statistics, with the addition of a
few additional identifiers.
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [7].
General Report Event:
Johnston, et al. Expires January 16, 2005 [Page 5]
Internet-Draft RTCP Summary Delivery July 2004
VQEvent = LocalMetrics CLRF
RemoteMetrics
LocalMetrics = ("LocalMetrics") HCOLON VoiceQualityMetrics
RemoteMetrics = ("RemoteMetrics") HCOLON VoiceQualityMetrics
VoiceQualityMetrics = ("VQMetrics") HCOLON CLRF
CodecInfo CRLF
JitterBufferInfo CRLF
PacketLossMetrics CRLF
BurstMetrics CLRF
GapMetrics CLRF
DelayMetrics CLRF
SignalMetrics CLRF
QualityScores CLRF
CodecInfo = ("codec") EQUALS c-type SPACE packet-rate SPACE pl-conceal
c-type = ("type") HCOLON HEX (HH)
packet-rate = ("prate") HCOLON HEX (HH)
pl-conceal = ("plc") HCOLON ("std" | "enh" | "unk")
JitterBufferInfo = ("jb") EQUALS jb-type SPACE jb-rate SPACE jb-nominal
SPACE jb-max SPACE jb-abs-max
jb-type = ("type") HCOLON ("adapt" | "non-adapt" | "unknown")
jb-rate = ("rate") HCOLON HEX (HHH)
jb-max = ("max") HCOLON HEX (HHH)
jb-nominal = ("nom") HCOLON HEX (HHH)
jb-absmax = ("abmax") HCOLON HEX (HHH)
PacketLossMetrics = ("pl") 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
Johnston, et al. Expires January 16, 2005 [Page 6]
Internet-Draft RTCP Summary Delivery July 2004
signal = ("sig") HCOLON HEX (HH)
echo-return-loss = ("erl") HCOLON HEX (HH)
noise = ("n") HCOLON HEX (HH)
QualityScores = ("qs") EQUALS r-lq SPACE r-cg SPACE mos-lq SPACE mos-cq
r-lq = ("r-lq") HCOLON HEX (HH)
r-cq = ("r-cg") HCOLON HEX (HH)
mos-lq = ("m-lq") HCOLON HEX (H"."H)
mos-cq = ("m-cq") 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 SPACE
Severity CRLF VoiceQualityMetrics
ViolationMetric = ("Type") HCOLON ("r-lq" / "r-cq" / "burst" / "erl"
/ "delay" / token )
Severity = ("Severity") HCOLON ("Warning" | "Critical" | "Clear")
6.6 Metric Definitions
Codec Type
The IANA defined audio codec value.
Packetization Rate
The rate, in milliseconds, at which the source audio is sampled.
See RFC 3611 [4] for a full description of these metrics.
Packet Loss Concealment
Indicator of whether packet loss concealment is used. When PLC
= "std", or standard, then a simple replay or interpolation
algorithm is being used to fill-in the missing packet; this
approach is typically able to conceal isolated lost packets at
low packet loss rates. When PLC = "enh", or enhanced, then an
enhanced interpolation algorithm is being used; algorithms of
this type are able to conceal high packet loss rates
effectively. When PLC = "unk", then no information is available
Johnston, et al. Expires January 16, 2005 [Page 7]
Internet-Draft RTCP Summary Delivery July 2004
concerning the use of PLC; however, for some codecs this may be
inferred.
Jitter Buffer Type
Indicator of the jitter buffer is adaptive or static. When the
jitter buffer is adaptive, then its size is being dynamically
adjusted to deal with varying levels of jitter. When non-
adaptive, the jitter buffer size is maintained at a fixed level.
Jitter Buffer Rate
This represents the implementation specific adjustment rate of a
jitter buffer in adaptive mode.
Jitter Buffer Nomimal Delay
This is the current nominal jitter buffer delay in
milliseconds, which corresponds to the nominal jitter buffer
delay for packets that arrive exactly on time. This parameter
MUST be provided for both fixed and adaptive jitter buffer
implementations.
Jitter Buffer Maximum Delay
This is the current maximum jitter buffer delay in milliseconds
which corresponds to the earliest arriving packet that would
not be discarded. In simple queue implementations this may
correspond to the nominal size. In adaptive jitter buffer
implementations, this value may dynamically vary up to JB abs
max (see below).
Jitter Buffer Absolute Maximum Delay
This is the absolute maximum delay in milliseconds that the
adaptive jitter buffer can reach under worst case conditions.
If this value exceeds 65535 milliseconds, then this field SHALL
convey the value 65535. This parameter MUST be provided for
adaptive jitter buffer implementations and its value MUST be
set to JB maximum for fixed jitter buffer implementations.
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.
Johnston, et al. Expires January 16, 2005 [Page 8]
Internet-Draft RTCP Summary Delivery July 2004
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 - Listening Quality
Estimated listening call quality expressed in a score from
0 - 100, per ITU-T standard G.107.
R - Conversational Quality
Estimated conversational call quality expressed in a
score from
0 - 100, per ITU-T standard G.107.
MOS-LQ
Estimated listening call quality expressed as a MOS score
MOS-CQ
Estimated conversational call quality expressed as a
MOS score
6.7 Use of PUBLISH Method
A VoIP application which supports this specification will publish
performance report information using the PUBLISH method. An
application wishing to access this performance data maintains a State
Agent for the perfrpt event package. The Request-URI of the PUBLISH
Johnston, et al. Expires January 16, 2005 [Page 9]
Internet-Draft RTCP Summary Delivery July 2004
method is set to the AOR of the VoIP application. The PUBLISH method
is sent to the normal default outbound proxy server of the VoIP
application.
The State Agent can use normal mechanisms for publication throttling
or rejection of the information as described in the PUBLISH [8]
specification.
6.8 Examples
Call Alert Scenario
PUBLISH sip:alice@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP pc22.example.com;branch=z9hG4bK3343d7
Max-Forwards: 70
To: <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=a3343df32
Call-ID: k3l43id034kevnx7334s
CSeq: 4321 PUBLISH
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: perfrpt
Accept: application/sdp, message/sipfrag
Content-Type: application/rtcp-xr
Content-Length: ...
Event:perfrpt
VQAlert: AlertType:r-lq Severity:Warning
LocalMetrics:VQMetrics:
codec=type:0 prate:20 plc:enh
jb=type:adapt rate:2 nom:40 max:80 abmax:120
pl=loss:5 disc:2
burst=den:0 len:0
gap=den:2 len:0
delay=rt:200 es:140
signal=sig:2 rerl:14 n:1
qs=r-lq:82 r-cq:80 ml:3.4 mc:3.3
RemoteMetrics:VQMetrics:
codec=type:0 prate:20 plc:std
jb=type:adapt rate:2 nom:40 max:80 abmax:120
plm=loss:02 disc:01
burst=den:0 len:0
gap=den:2 len:0
delay=rt:100 es:140
signal=sig:2 rerl:14 n:1
qs=r-lq:81 r-cq:90 ml:3.1 mc:3.2
DialogID:38419823470834;to-tag=8472761;from-tag=9123dh311
Johnston, et al. Expires January 16, 2005 [Page 10]
Internet-Draft RTCP Summary Delivery July 2004
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. The remote metrics were available
via RTCP XR [4 ] so they are also included in the event.
End of Session Scenario
PUBLISH sip:alice@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP pc22.example.com;branch=z9hG4bK3343d7
Max-Forwards: 70
To: <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=a3343df32
Call-ID: k3l43id034kevnx7334s
CSeq: 4331 PUBLISH
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: perfrpt
Accept: application/sdp, message/sipfrag
Content-Type: application/rtcp-xr
Content-Length: ...
Event:perfrpt
LocalMetrics:VQMetrics:
codec=type:0 prate:20 plc:std
jb=type:adapt rate:2 nom:40 max:80 abmax:120
pl=loss:05 disc:02
burst=den:0 len:0
gap=den:2 len:0
delay=rt:200 es:140
signal=sig:2 rerl:14 n:1
qs=r-lq:90 r-cq:80 ml:3.4 mc:3.3
RemoteMetrics:VQMetrics:
codec=type:0 prate:20 plc:std
jb=type:adapt rate:2 nom:40 max:80 abmax:120
pl=loss:02 disc:01
burst=den:0 len:0
gap=den:2 len:0
dly=rt:100 es:140
sig=sig:2 rerl:14 n:1
qs=r-lq:90 r-cq:90 ml:3.1 mc:3.2
DialogID:38419823470834;to-tag=8472761;from-tag=9123dh311
This event report provides the parameters as they were at the end of
the session.
Johnston, et al. Expires January 16, 2005 [Page 11]
Internet-Draft RTCP Summary Delivery July 2004
7. Call Flow Examples
This section shows a number of call flow examples showing how the
event package works.
7.1 End of Session Notification Call Flow
Alice Proxy/Registrar Collector Bob
| | | |
| | | |
| REGISTER Allow-Event:perfrpt F1 | |
|------------------->| | |
| 200 OK F2 | | |
|<-------------------| | |
| INVITE F3 | | |
|------------------->| | |
| | INVITE F4 | |
| |---------------------------------------->|
| | 200 OK F5 | |
| |<----------------------------------------|
| 200 OK F6 | | |
|<-------------------| | |
| ACK F7 | | |
|------------------->| | |
| | ACK F8 | |
| |---------------------------------------->|
| RTP | | |
|<============================================================>|
| RTCP | | |
|<============================================================>|
| | | |
| BYE F9 | | |
|------------------->| BYE F10 | |
| |---------------------------------------->|
| | 200 OK F11 | |
| |<----------------------------------------|
| 200 OK F12 | | |
|<-------------------| | |
| PUBLISH Event:perfrpt F13 | |
|------------------->| | |
| | PUBLISH Event:perfrpt F14 |
| |------------------->| |
| | 200 OK F15 | |
| |<-------------------| |
| 200 OK F16 | | |
|<-------------------| | |
Figure 1. Summary report sent after session termination.
Johnston, et al. Expires January 16, 2005 [Page 12]
Internet-Draft RTCP Summary Delivery July 2004
7.2 Mid Session Report
Alice Proxy/Registrar Collector Bob
| | | |
| INVITE F1 | | |
|------------------->| | |
| | INVITE F2 | |
| |---------------------------------------->|
| | 200 OK F3 | |
| |<----------------------------------------|
| 200 OK F4 | | |
|<-------------------| | |
| ACK F5 | | |
|------------------->| | |
| | ACK F6 | |
| |---------------------------------------->|
| RTP | | |
|<============================================================>|
| RTCP | | |
|<============================================================>|
| PUBLISH Event:perfrpt F7 | |
|------------------->| | |
| | PUBLISH Event:perfrpt F8 |
| |------------------->| |
| | 200 OK F9 | |
| |<-------------------| |
| 200 OK F10 | | |
|<-------------------| | |
| | | |
| BYE F12 | | |
|------------------->| BYE F13 | |
| |---------------------------------------->|
| | 200 OK F14 | |
| |<----------------------------------------|
| 200 OK F15 | | |
|<-------------------| | |
| PUBLISH Event:perfrpt F16 | |
|------------------->| | |
| | PUBLISH Event:perfrpt F17 |
| |------------------->| |
| | 200 OK F18 | |
| |<-------------------| |
| 200 OK F19 | | |
|<-------------------| | |
Figure 2. Summary report sent during session with threshold report.
Johnston, et al. Expires January 16, 2005 [Page 13]
Internet-Draft RTCP Summary Delivery July 2004
8. IANA Considerations
This document registers a new SIP Event Package and a new MIME type.
8.1 SIP Event Package Registration
Package name: perfrpt
Type: package
Contact: Alan Johnston <alan.johnston@mci.com>
Published Specification: This document
Johnston, et al. Expires January 16, 2005 [Page 14]
Internet-Draft RTCP Summary Delivery July 2004
8.2 application/rtcp-xr MIME Registration
MIME media type name: application
MIME subtype name: rtcp-xr
Mandatory parameters: none
Optional parameters: none
Encoding considerations: text
Security considerations: See next section.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type is
being used in notifications of VoIP quality reports.
Additional Information:
Magic Number: None
File Extension: None
Macintosh file type code: "TEXT"
Personal and email address for further information: Alan Johnston
<alan.johnston@mci.com>
Intended usage: COMMON
Author/Change controller: The IETF.
9. 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.
Johnston, et al. Expires January 16, 2005 [Page 15]
Internet-Draft RTCP Summary Delivery July 2004
10. Updates since -02
- Removed discussion of alternative mechanisms
- Changed from NOTIFY transport to PUBLISH transport.
- Changed package name from "rtcp-xr" to "perfrpt"
- Corrected call flows.
- Minor updates to message body format.
- Added IANA registration for perfrpt SIP Event Package and
application/rtcp-xr MIME registration.
- Added more discussion for motivation and reasons why SNMP is not
suitable
11. Contributors
The authors would like to thank Dave Oran and Tom Redman for their
discussions.
12 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", STD 64,
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.
Johnston, et al. Expires January 16, 2005 [Page 16]
Internet-Draft RTCP Summary Delivery July 2004
[8] Niemi, A., "An Event State Publication Extension to the Session
Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in
progress), May 2004.
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
Amy Pendleton
Nortel Networks
2380 Performance Drive
Richardson, TX 75081
EMail: aspen@nortelnetworks.com
Johnston, et al. Expires January 16, 2005 [Page 17]
Internet-Draft RTCP Summary Delivery July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Johnston, et al. Expires January 16, 2005 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-26 11:17:30 |