One document matched: draft-johnston-sipping-rtcp-summary-02.txt
Differences from draft-johnston-sipping-rtcp-summary-01.txt
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: <sip:collector@chicago.example.com>;tag=43524545
From: Alice <sip:alice@example.com>;tag=a3343df32
Call-ID: k3l43id034kevnx7334s
CSeq: 4321 NOTIFY
Contact: <sip:alice@pc22.example.com>
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]
| PAFTECH AB 2003-2026 | 2026-04-21 22:16:44 |