Network Working Group I. Johansson
Internet-Draft M. Westerlund
Intended status: Standards Track Ericsson AB
Expires: October 26, 2008 Apr 24, 2008
Support for non-compound RTCP, opportunities and consequences
draft-ietf-avt-rtcp-non-compound-04
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 October 26, 2008.
Abstract
This memo discusses benefits and issues that arise when allowing RTCP
packets to be transmitted as non-compound packets, i.e not follow the
rules of RFC 3550. Based on that analysis this memo proposes changes
to the rules to allow feedback messages to be sent as non-compound
RTCP packets when using the RTP AVPF profile (RFC 4585) under certain
conditions.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
Johansson & Westerlund Expires October 26, 2008 [Page 1]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RTCP Compound Packets . . . . . . . . . . . . . . . . . . . . 3
3. Benefits with non-compound packets . . . . . . . . . . . . . . 4
3.1. Low birate links . . . . . . . . . . . . . . . . . . . . . 5
3.2. Higher bitrates . . . . . . . . . . . . . . . . . . . . . 5
3.3. Both high and low bitrate links . . . . . . . . . . . . . 6
4. Use cases for non-compound RTCP . . . . . . . . . . . . . . . 6
4.1. Control plane signaling . . . . . . . . . . . . . . . . . 6
4.2. Codec control signaling . . . . . . . . . . . . . . . . . 6
4.3. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Status reports . . . . . . . . . . . . . . . . . . . . . . 7
5. Issues with non-compound RTCP packets . . . . . . . . . . . . 8
5.1. Middle boxes . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Packet Validation . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Old RTCP Receivers . . . . . . . . . . . . . . . . . . 8
5.2.2. Weakened Packet Validation . . . . . . . . . . . . . . 8
5.2.3. Bandwidth considerations . . . . . . . . . . . . . . . 9
5.2.4. Computation of avg_rtcp_size . . . . . . . . . . . . . 9
5.3. Encryption/authentication . . . . . . . . . . . . . . . . 9
5.4. RTP and RTCP multiplex on the same port . . . . . . . . . 9
5.5. Header compression . . . . . . . . . . . . . . . . . . . . 10
6. Rules and guidelines for non-compound packets in AVPF . . . . 10
6.1. Definition of non-compound RTCP . . . . . . . . . . . . . 11
6.2. Algorithm considerations . . . . . . . . . . . . . . . . . 11
6.2.1. Verification of delivery . . . . . . . . . . . . . . . 11
6.2.2. Single vs multiple RTCP in a non-compound RTCP . . . . 12
6.2.3. Enforcing compound RTCP . . . . . . . . . . . . . . . 12
6.2.4. Immediate mode . . . . . . . . . . . . . . . . . . . . 12
6.3. SDP Signalling Attribute . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Johansson & Westerlund Expires October 26, 2008 [Page 2]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
1. Introduction
In RTP [RFC3550] it is currently mandatory to always use RTCP
compound packets containing at least Sender Reports or Receiver
reports, and a SDES packet containing at least the CNAME item. There
are good reasons for this as discussed below (see Section 2).
However this do result in that the minimal RTCP packets are quite
large. The RTP profile AVPF [RFC4585] specifies new RTCP packet
types for feedback messages. Some of these feedback messages would
benefit from being transmitted with minimal delay and AVPF do provide
some mechanism to enable this. However for environments with low-
bitrate links this still consumes quite large amount of resources and
introduce extra delay in the time it takes to completely send the
compound packet in the network. There are also other benefits as
discussed in Section 3.
The use of non-compound packets is not without issues. This is
discussed in Section 5. These issues needs to be considered and are
part of the motivation for this document.
In addition this document proposes how AVPF could be updated to allow
the transmission of non-compound packets in a way that would not
substantially affect the mechanisms that compound packets provide.
The connection to AVPF is motivated by the fact that non-compound
RTCP is mainly intended for event driven feedback purposes and that
the AVPF early and immediate modes make this possible.
2. RTCP Compound Packets
Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent
in a compound packet consisting of at least two individual packets,
first an Sender Report (SR) or Receiver Report (RR), followed by
additional packets including a mandatory SDES packet containing a
CNAME Item for the transmitting source identifier (SSRC). Lets
examine what these RTCP packet types are used for.
1. The sender and receiver reports (see Section 6.4 of [RFC3550])
provides the RTP session participant with the Sender Source
Identifier (SSRC) of all RTCP senders. Having all participants
send these packets periodically allows everyone to determine the
current number of participants. This information is used in the
transmission scheduling algorithm. Thus this is particularly
important for new participants so that they quickly can establish
a good estimate of the group size. Failure to do this would
result in RTCP senders consuming to much bandwidth.
Johansson & Westerlund Expires October 26, 2008 [Page 3]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
2. The sender and receiver reports contain some basic statistics
usable for monitoring of the transport and thus enable
adaptation. These reports become more useful if sent regularly
as the receiver of a report can perform analysis to find trends
between the individual reports. When used for media transmission
adaptation the information become more useful the more frequently
it is received, at least until one report per round-trip time
(RTT) is achieved. Therefore there are most cases no reason to
not include the sender or receiver report in all RTCP packets.
3. The CNAME SDES item (See Section 6.5.1 of [RFC3550]) exists to
allow receivers to determine which media flows that should be
synchronized with each other between different RTP sessions
carrying different media types. Thus it is important to quickly
receive this for each media sender in the session when joining an
RTP session.
4. Sender Reports (SR) is used in combination with the above SDES
CNAME mechanism to synchronize multiple RTP streams, such as
audio and video. After having determined which media streams
should be synchronized using the CNAME field, the receiver uses
the Sender Report's NTP and RTP timestamp fields to establish
synchronization.
Reviewing the above it is obvious that both SR/RR and the CNAME are
very important for new session participants to be able to utilize any
received media and to avoid flooding the network with RTCP reports.
In addition, if not sent regularly the dynamic nature of the
information provided would make it less and less useful.
3. Benefits with non-compound packets
As mentioned in the introduction, most advantages of using non-
compound packets exists in cases when the available RTCP bitrate is
limited. This because non-compound packets will be substantially
smaller than compound packets. A compound packet is forced to
contain both an RR or an SR and the CNAME SDES item. The RR
containing a report block for a single source is 32 bytes, an SR is
52 bytes. Both may be larger if they contain report blocks for
multiple sources. The SDES packet containing a CNAME item will be 10
bytes plus the CNAME string length. Here it is reasonable that the
CNAME string is at least 10 bytes to get a decent collision
resistance. And if the recommended form of user@host is used, then
most strings will be longer than 20 characters. Thus a non-compound
packet can become at least 70-80 bytes smaller than the compound
packet.
Johansson & Westerlund Expires October 26, 2008 [Page 4]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
The following benefits exist for the non-compound packets,
3.1. Low birate links
For low birate links the benefits are as follows.
o For links where the packet loss rate grows with the packet size,
smaller packets are be less likely to be dropped. An example of
such links are radio links. In the cellular world there exist
links that are optimized to handle RTP packets sized for carrying
compressed speec. This increases the capacity and coverage for
voice services in a given wireless network. Minimum sized
compound RTCP packets are commonly 2-3 times the size of a RTP
packet carrying compressed speech. If the speech packet over such
a bearer has a packet loss probability of p, then the RTCP packet
will experience a loss probability of 1-(1-p)^x where x is the
number of fragments the compound packet will be split on the link
layer, i.e. commonly into 2 or 3 fragments.
o Shorter serialization time, i.e the time it takes the link to
transmit the packet. For slower links this time can be
substantial. For example transmitting 120 bytes over an link
interface capable of 30 kbps takes 32 milliseconds (ms) assuming
uniform transmission rate.
In cases when non-compound packets carry important and time sensitive
feedback, both shorter serialization time and the lower loss
probability are important to enable the best possible functionality.
Having a packet loss rate that is much higher for the feedback
packets compared to media packets hurts when trying to perform media
adaptation, to for example handle the changed performance present at
the cell border in cellular system.
3.2. Higher bitrates
For high bitrate applications there is usually no problem of
supplying RTCP with sufficient bitrates. When using AVPF one can use
the "trr-int" parameter to restrict the regular reporting interval to
approximately once per RTT or less often. As in most cases there is
little reason to provide with regular reports of higher density than
this. Any additional bandwidth can then be used for feedback
messages. The benefit of non-compound packets in this case is
limited, but exists. One typical example is video using generic NACK
in cases where the RTT is low. Using non-compound packets would
reduce the total amount of bits used for RTCP. This is primarily
applicable if the number of non-compound packets is large. This
would also result in lower processing delay and less complexity for
the feedback packets as they do not need to query the RTCP database
Johansson & Westerlund Expires October 26, 2008 [Page 5]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
to construct the right messages.
As message size generally is a smaller issue for higher birates, it
is also possible to transmit multiple RTCP in each lower layer
datagram in these cases. The motivation behind non-compound RTCP is
in this case is not size, rather it is to avoid the extra overhead
caused by inclusion of the SR/RR and SDES CNAME items in each
transmitted RTCP.
3.3. Both high and low bitrate links
Independently of the link type there are additional benefits with
sending feedback in small non-compound RTCP.
o Applications that use RTCP AVPF in early or immediate mode to send
frequent event driven feedback. Under these circumstances non-
compound RTCP reduces the risk that the RTCP bandwidth becomes too
high during periods of heavy adaptation feedback signaling.
o In cases when regular feedback is needed, such as the profile
under development for TCP friendly rate control (TFRC) for RTP
[I-D.ietf-avt-tfrc-profile], the size of compound RTCP can result
in very high bandwidth requirements if the round trip time is
short. For this particular application non-compound RTCP gives a
very substantial improvement.
4. Use cases for non-compound RTCP
Below are listed a few use cases for non-compound RTCP. The current
use of non-compound RTCP is very application specific. A general
definition of the use of non-compound RTCP for e.g control plane or
codec control signaling would probably need to be specified within
the IETF.
4.1. Control plane signaling
Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [OMA-PoC]
makes use of non-compound packets when transmitting certain events.
The OMA POC service is primarily used over cellular links capable of
IP transport, such as the GSM GPRS.
4.2. Codec control signaling
Examples of codec control usage for non-compound RTCP are found in
[3GPP-MTSI].
Another example that can be used with non-compound RTCP is e.g TMMBR
Johansson & Westerlund Expires October 26, 2008 [Page 6]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
messages as specified in [RFC5104] which signal a request for a
change in codec bitrate. The benefit of non-compound RTCP for these
messages is that in bad channel conditions, a non-compound RTCP can
be considerably more likely to be received than larger compound RTCP
messages. This is critical as these messages are likely to occur
when channel conditions are poor.
4.3. Feedback
An example of a feedback scenario that would benefit from non-
compound RTCP is Video streams with generic NACK. In cases where the
RTT is shorter than the receiver buffer depth, generic NACK can be
used to request retransmission of missing packets, thus improving
playout quality considerably. If the generic NACK packets are
transmitted as non-compound packets, the bandwidth requirement for
RTCP will be minimal, enabling more frequent feedback. Like in the
Codec control case it is important that these packets can be
transmitted with as little delay as possible.
Another interesting use for non-compound RTCP is in cases when
regular feedback is needed, such as the profile under development for
TCP friendly rate control (TFRC) for RTP [I-D.ietf-avt-tfrc-profile].
The size of compound RTCP can result in very high bandwidth
requirements for the feedback when the round trip time is short. For
this particular application non-compound RTCP may give a very
substantial improvement.
4.4. Status reports
One proposed idea is to transmit small measurement or status reports
in non-compound RTCP, and to be able to split the sub-packets of a
minimum compound RTCP and transmit them separately. The status
reports can be used either by the endpoints or by other network
monitoring boxes in the network.
The benefit is that with some radio access technologies small packets
are more robust to poor radio conditions than large packets.
Additionally, with small (report) packets there is a smaller risk
that the report packets will affect the channel that they report
upon.
Another benefit is that it is, with non-compound RTCP, possible to
allow e.g anonymous status reportorting to be transmitted
unencrypted. Something that may be beneficial for e.g network
monitoring purposes.
Johansson & Westerlund Expires October 26, 2008 [Page 7]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
5. Issues with non-compound RTCP packets
This section describes the known issues with non-compound RTCP
packets and also a brief analysis.
5.1. Middle boxes
Middle boxes in the network may discard RTCP packets that do not
follow the rules outlined in section 6.1 of RFC3550. Newer report
types may be interptered as unknown by the middle box. For instance
if the payload type number is 207 instead of 200 or 201 it may be
treated as unknown. The effect of this might for instance be that
compound RTCP packets would get through while the non-compound
feedback packets would be lost.
Verification of the delivery of non-compound RTCP is discussed in
Section 6.2.1.
5.2. Packet Validation
A non-compound packet will be discarded by the packet validation code
in Appendix A of [RFC3550]. This has several impacts as described in
the following sub sections.
5.2.1. Old RTCP Receivers
Any RTCP receiver without updated packet validation code will discard
the non-compound packets. Thus these receivers will not see the
feedback contained in the these non-compound packets. The effect of
this depends on the type of feedback message and the role of the
receiver. For example this may cause complete function loss in the
case of attempting to use a non-compound NACK message (see Section
6.2.1 of [RFC4585]) to non updated media sender in a session using
the retransmission scheme defined by [RFC4588].
This type of discarding would also effect the feedback suppression
defined in AVPF. The result would be a partitioning of the receivers
within the session between old ones only seeing the compound RTCP
feedback messages and the newer ones seeing both. Where the old ones
may send feedback messages for events already reported on in non-
compound packets.
5.2.2. Weakened Packet Validation
The packet validation code needs to be rewritten to accept non-
compound packets. This in particular affects section 9.1 in
[RFC3550] in the sense that the header verification must take into
account that the payload type numbers for the (first) RTCP packet may
Johansson & Westerlund Expires October 26, 2008 [Page 8]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
differ from 200 or 201 (SR or RR).
One potential effect of this change is much weaker validation that
received packets actually are RTCP packets, and not packets of some
other type being wrongly delivered. Thus some consideration should
be done to ensure the best possible validation is available. For
example restricting non-compound packets to contain only some
specific RTCP packet types, that is preferably signalled on a session
basis.
5.2.3. Bandwidth considerations
The discarding of non-compound RTCP packets would effect the RTCP
transmission calculation in the following way: the avg_rtcp_size
value would become larger than for RTP receivers that exclude the
non-compound in this calculation (assuming that non-compound packets
are smaller than compound ones). Therefore these senders would
under-utilize the available bitrate and send with a longer interval
than updated receivers. For most sessions this should not be an
issue. However for sessions with a large portion of non-compound
packets may result in that the updated receivers time out non-updated
senders prematurely. A solution to this is presented in Section 6.2.
5.2.4. Computation of avg_rtcp_size
Long intervals between compound RTCP packets and many non-compound
RTCP packets in between may lead to a computation of a value for
avg_rtcp_size that varies greatly over time. This is discussed more
in Section 6.2.
5.3. Encryption/authentication
SRTP presents a problem for non-compound RTCP. Section 3.4 in
[RFC3711] states "SRTCP MUST be given packets according to that
requirement in the sense that the first part MUST be a sender report
or a receiver report".
However the same text also states that the encryption prefix that is
present in the receiver and sender reports should not be used by
SRTP. The conclusion is therefore that it is possible to use non-
compound RTCP with SRTP.
5.4. RTP and RTCP multiplex on the same port
In applications which multiplex RTP and RTCP on the same port, as
defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to
ensure that the de-multiplexing is done properly even though RTCP
packets are non-compound.
Johansson & Westerlund Expires October 26, 2008 [Page 9]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
5.5. Header compression
Two issues are related to header compression:
o Payload type number identification: The RoHC header compression
algorithm algorithm [RFC3095] needs to create different
compression contexts for RTP and RTCP for optimum performance. If
RTP and RTCP are multiplexed on the same port the classification
is based on payload type numbers. The classification algorithm
must here acklowledge the fact that the payload type number for
(the first) RTCP may differ from 200 or 201.
o Compression of RTCP packets: No IETF defined header compression
method compress RTCP packets, however if such methods are
developed in the future, these methods must take non-compound RTCP
in account.
6. Rules and guidelines for non-compound packets in AVPF
Based on the above analysis it seems feasible to allow transmission
of non-compound RTCP under some restrictions.
First of all it is important that compound packets are transmitted at
regular intervals to ensure that the feedback reporting works. The
tracking of session size and number of participants is also important
as this ensures that the RTCP bandwidth remain bounded independent of
the number of session participants.
As the compound packets are also used to establish the
synchronization, any newly joining participant in a session would
need to receive a compound packet from the media sender.
In summary the regular usage of compound packets must be maintained
throughout the complete session. Thus non-compound packets should be
restricted to be used as extra RTCP (e.g feedback) sent in cases when
a regular compound packet would not have been sent.
The usage of non-compound RTCP packet SHALL only be done in RTP
sessions operating in AVPF [RFC4585] Early RTCP or Immediate feedback
mode. Non-compound packets SHALL NOT be sent until at least one
compound packet has been sent. In Immediate feedback mode all
feedback messages MAY be sent as non-compound packets. In early RTCP
mode a feedback message scheduled for transmission as an Early RTCP
packet, i.e not a Regular RTCP packet, MAY be sent as a non-compound
packet. All packets that are scheduled for transmission as Regular
RTCP packets SHALL be sent as (full) compound RTCP packets as
indicated by AVPF [RFC4585].
Johansson & Westerlund Expires October 26, 2008 [Page 10]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
6.1. Definition of non-compound RTCP
A non-compound RTCP is a packet that deviates from the rules
regarding (minimal) compound RTCP given in RFC3550/4585 in the aspect
that they don't contain both the mandatory elements SR/RR and SDES-
CNAME. The definition does not make any distinction based on size.
This means that it is possible to transmit multiple RTCP in one lower
layer datagram.
6.2. Algorithm considerations
6.2.1. Verification of delivery
If an application is to use non-compound packets it is important to
verify that they actually reach the session participants. As
outlined above in Section 5.1 and Section 5.2 packets may be
discarded along the path or in the end-point.
The end-points can be resolved by introducing signaling that informs
if all session participants are capable of non-compound packets or
not.
The middle box issue is more difficult and here one will be required
to use heuristics to determine if the non-compound packets are
delivered or not. However in many cases the feedback messages sent
using non-compound packets will result in either explicit or implicit
indications that they have been received. Example of such are the
RTP retransmission [RFC4588] that result from a NACK message
[RFC4585], the Temporary Maximum Media Bitrate Notification message
resulting from a Temporary Maximum Media Bitrate Request [RFC5104],
or the presence of a Decoder Refresh Point [RFC5104] in the video
media stream resulting from the Full Intra Request sent.
An algorithm to detect consistent failure of delivery of non-compound
packets must be used by any application using non-compound. The
details of this algorithm is application dependent and therefore
outside the scope of this document.
A method to detect if non-compound RTCP are discarded is to send a
non-compound SR packet, then check that the timestamp is echoed back
in the corresponding RR packet. This verification method is not
compelety safe however as it SR is still one of the expected packet
types.
If the verification fails it is strongly RECOMMENDED that only
compound RTCP according to the rules outlined in RFC3550 is
transmitted.
Johansson & Westerlund Expires October 26, 2008 [Page 11]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
6.2.2. Single vs multiple RTCP in a non-compound RTCP
The result of the definition in Section 6.1 may be that the resulting
size of non-compound RTCP can become larger than a normal compound
RTCP. For applications that use access types that are sensitive to
packet size (see Section 3.1) it is strongly RECOMMENDED that the use
of non-compound RTCP is limited to the transmission of single RTCP
packets in each lower layer datagram.
The methods to detemine the need for this is outside the scope of
this draft.
6.2.3. Enforcing compound RTCP
As discussed earlier it is important that the transmission of
compound RTCP packets occurs at regular intervals. However, this
will occur as long as the RTCP senders follow the AVPF scheduling
algorithm defined in Section 3.5 in [RFC4585]. This as all regular
RTCP packets must be full compound RTCP packets. Note that also in
immediate mode is there a requirement on sending regular RTCP
packets.
6.2.4. Immediate mode
Section 3.3 in RFC4585 gives the option to use AVPF Immediate mode as
long as the groupsize is below a certain limit. As feedback using
non-compound RTCP may become smaller it opens up for a more liberal
use of immediate mode.
6.3. SDP Signalling Attribute
We request to define the a "a=rtcp-nc" [RFC4566] attribute to
indicate if the session participant is capable of supporting non-
compound packets. It is a required that a participant that proposes
the use of non-compound RTCP itself supports the reception of non-
compound RTCP.
An offering client that wish to use non-compound RTCP MUST include
the attribute "a=rtcp-nc" in the SDP offer. If "a=rtcp-nc" is
present in the offer SDP, the answerer that supports non-compound
RTCP and wishes to use it SHALL include the "a=rtcp-nc" attribute in
the answer.
7. IANA Considerations
Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute:
Johansson & Westerlund Expires October 26, 2008 [Page 12]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
o Contact name, email address and telephone number: Authors of
RFCXXXX
o Attribute-name: rtcp-nc
o Long-form attribute name: Non-compound RTCP
o Type of attribute: media-level
o Subject to charset: no
This attribute defines the support for non-compound RTCP, i.e the
possibility to transmit RTCP that does not comform to the rules for
compund RTCP defined in RFC3550. It is a property attribute, which
does not take a value.
Note to RFC Editor: please replace "RFC XXXX" above with the RFC
number of this memo, and remove this note.
8. Security Considerations
The security considerations of RTP [RFC3550] and AVPF [RFC4585] will
apply also to non-compound packets. The reduction in validation
strength for received packets on the RTCP port may result in a higher
degree of acceptance of spurious data as real RTCP packets. This
vulnerability can mostly be addressed by usage of any security
mechanism that provide authentication, one example such mechanism is
SRTP [RFC3711].
9. Acknowledgements
The authors would like to thank all the people who gave feedback on
this document.
This document also contain some text copied from [RFC3550],
[RFC4585]and [RFC3711]. We take the opportunity to thank the authors
of said documents.
10. References
10.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Johansson & Westerlund Expires October 26, 2008 [Page 13]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
10.2. Informative References
[3GPP-MTSI]
3GPP, "Specification : 3GPP TS 26.114 (v7.4.0), http://
www.3gpp.org/ftp/Specs/archive/26_series/26.114/
26114-740.zip", March 2007.
[I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-avt-tfrc-profile]
Gharai, L., "RTP with TCP Friendly Rate Control",
draft-ietf-avt-tfrc-profile-10 (work in progress),
July 2007.
[OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over
Cellular User Plane, http://www.openmobilealliance.org/
release_program/docs/PoC/V1_0_1-20061128-A/
OMA-TS-PoC-UserPlane-V1_0_1-20061128-A.pdf",
November 2006.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
Johansson & Westerlund Expires October 26, 2008 [Page 14]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
Authors' Addresses
Ingemar Johansson
Ericsson AB
Laboratoriegrand 11
SE-971 28 Lulea
SWEDEN
Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com
Magnus Westerlund
Ericsson AB
Torshamnsgatan 21-23
SE-164 83 Stockholm
SWEDEN
Phone: +46 8 7190000
Email: magnus.westerlund (AT) ericsson.com
Johansson & Westerlund Expires October 26, 2008 [Page 15]
Internet-Draft Non-compound RTCP in RTP profile Apr 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Johansson & Westerlund Expires October 26, 2008 [Page 16]
