TOC |
|
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 November 21, 2008.
This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size such that mandatory report types according to the rules outlined in RFC3550 are removed. Based on that analysis this memo proposes changes to the rules to allow feedback messages to be sent as reduced size RTCP packets when using the RTP AVPF profile (RFC 4585) under certain conditions.
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
1.
Glossary
2.
Introduction
3.
RTCP Compound Packets
4.
Benefits with reduced size RTCP
4.1.
Low birate links
4.2.
Higher bitrates
4.3.
Both high and low bitrate links
5.
Use cases for reduced size RTCP
5.1.
Control plane signaling
5.2.
Codec control signaling
5.3.
Feedback
5.4.
Status reports
6.
Issues with reduced size RTCP
6.1.
Middle boxes
6.2.
Packet Validation
6.2.1.
Old RTCP Receivers
6.2.2.
Weakened Packet Validation
6.2.3.
Bandwidth considerations
6.2.4.
Computation of avg_rtcp_size
6.3.
Encryption/authentication
6.4.
RTP and RTCP multiplex on the same port
6.5.
Header compression
7.
Rules and guidelines for non-compound packets in AVPF
7.1.
Definition of non-compound RTCP
7.2.
Algorithm considerations
7.2.1.
Verification of delivery
7.2.2.
Single vs multiple RTCP in a reduced size RTCP
7.2.3.
Enforcing compound RTCP
7.2.4.
Immediate mode
7.3.
SDP Signalling Attribute
8.
IANA Considerations
9.
Security Considerations
10.
Acknowledgements
11.
References
11.1.
Normative References
11.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
TOC |
The naming convention for RTCP is often confusing. Below a list of RTCP terms and what they mean. See also section 6.1 in [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) and section 3.1 in [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),” July 2006.) for details.
TOC |
In RTP (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [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 3 (RTCP Compound Packets)). However this do result in that
the minimal RTCP packets are quite large.
The RTP profile AVPF (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),” July 2006.) [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 a large amount of resources
and introduces 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 4 (Benefits with reduced size RTCP).
The use of reduced size RTCP is not without issues. This is discussed in Section 6 (Issues with reduced size RTCP). 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 reduced size RTCP in a way that would not substantially affect the mechanisms that compound packets provide. The connection to AVPF is motivated by the fact that reduced size RTCP is mainly intended for event driven feedback purposes and that the AVPF early and immediate modes make this possible.
TOC |
Section 6.1 in [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) specifies that an RTCP packet must be sent as a compound RTCP consisting of at least two individual RTCP, 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). Below is a short description what these RTCP packet types are used for.
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.
TOC |
As mentioned in the introduction, most advantages of using reduced size RTCP packets exists in cases when the available RTCP bitrate is limited. This because they can become 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. If the recommended form of user@host is used, then most strings will be longer than 20 characters. Thus a reduced size RTCP can become at least 70-80 bytes smaller than the compound packet.
The following benefits exist for reduced size RTCP,
TOC |
For low bitrate links the benefits are as follows.
In cases when reduced size RTCP 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 a cellular system.
TOC |
For high bitrate applications there is usually no problem to supply 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 reduced size RTCP in this case is limited, but exists. One typical example is video using generic NACK in cases where the RTT is low. Using reduced size RTCP would reduce the total amount of bits used for RTCP. This is primarily applicable if the number of reports 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 to construct the right messages.
As message size is generally a smaller issue at higher bitrates, it is also possible to transmit multiple RTCP in each lower layer datagram in these cases. The motivation behind reduced size RTCP 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.
TOC |
Independently of the link type there are additional benefits with sending feedback in small reduced size RTCP.
TOC |
Below are listed a few use cases for reduced size RTCP. The current use of reduced size RTCP is very application specific. A general definition of the use of it for e.g control plane or codec control signaling would probably need to be specified in the IETF.
TOC |
Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [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.) makes use of reduced size RTCP when transmitting certain events. The OMA POC service is primarily used over cellular links capable of IP transport, such as the GSM GPRS.
TOC |
Examples of codec control usage for reduced size RTCP are found in [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.).
Another example that can be used with reduced size RTCP is e.g TMMBR messages as specified in [RFC5104] (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.) which signal a request for a change in codec bitrate. The benefit of its use for these messages is that in bad channel conditions as they are much more likely to be successfully received than larger compound RTCP. This is critical as these messages are likely to occur when channel conditions are poor.
TOC |
An example of a feedback scenario that would benefit from reduced size 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 reduced size RTCP, 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 reduced size RTCP is in cases when regular feedback is needed, as described in Section 4.3 (Both high and low bitrate links).
TOC |
One proposed idea is to transmit small measurement or status reports in reduced size RTCP, and to be able to split the minimal compound RTCP and transmit the individual RTCP 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 reduced size RTCP, possible to allow e.g anonymous status reporting to be transmitted unencrypted. Something that may be beneficial for e.g network monitoring purposes.
TOC |
This section describes the known issues with reduced size RTCP and also a brief analysis.
TOC |
Middle boxes in the network may discard RTCP that do not follow the rules outlined in section 6.1 of RFC3550. Newer report types may be interpreted 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 would get through while the reduced size RTCP would be lost.
Verification of the delivery of reduced size RTCP is discussed in Section 7.2.1 (Verification of delivery).
TOC |
A reduced size RTCP will be discarded by the packet validation code in Appendix A of [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.). This has several impacts as described in the following sub sections.
TOC |
Any RTCP receiver without updated packet validation code will discard the reduced size RTCP which means that the receiver will not see e.g the contained feedback messages. 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 reduced size NACK message (see Section 6.2.1 of [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),” July 2006.)) to non updated media sender in a session using the retransmission scheme defined by [RFC4588] (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.).
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 reduced size RTCP.
TOC |
The packet validation code needs to be rewritten to accept reduced size RTCP. This in particular affects section 9.1 in [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) in the sense that the header verification must take into account that the payload type numbers for the (first) RTCP in the lower layer datagram may differ from 200 or 201 (SR or RR).
One potential effect of this change is much weaker validation that received packets actually are RTCP, 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 reduced size RTCP to contain only some specific RTCP packet types, that is preferably signalled on a session basis.
TOC |
The discarding of reduced size RTCP 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 reduced size RTCP in this calculation (assuming that reduced size RTCP 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 reduced size RTCP may result in that the updated receivers time out non-updated senders prematurely. A solution to this is presented in Section 7.2 (Algorithm considerations).
TOC |
Long intervals between compound RTCP and many reduced size RTCP 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 7.2 (Algorithm considerations).
TOC |
SRTP presents a problem for reduced size RTCP. Section 3.4 in [RFC3711] (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) 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 reduced size RTCP with SRTP.
TOC |
In applications which multiplex RTP and RTCP on the same port, as defined in [I‑D.ietf‑avt‑rtp‑and‑rtcp‑mux] (Perkins, C. and M. Westerlund, “Multiplexing RTP Data and Control Packets on a Single Port,” August 2007.), care must be taken to ensure that the de-multiplexing is done properly even though RTCP are reduced size.
TOC |
Two issues are related to header compression:
TOC |
Based on the above analysis it seems feasible to allow transmission of reduced size RTCP under some restrictions.
First of all it is important that compound RTCP 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 RTCP are also used to establish and maintain synchronization between media, any newly joining participant in a session would need to receive compound RTCP from the media sender(s).
In summary the regular usage of compound RTCP must be maintained throughout the complete session. Thus reduced size RTCP should be restricted to be used as extra RTCP (e.g feedback) sent in cases when a regular compound RTCP would not have been sent.
The usage of reduced size RTCP SHALL only be done in RTP sessions operating in AVPF (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),” July 2006.) [RFC4585] Early or Immediate mode. Reduced size RTCP SHALL NOT be sent until at least one compound RTCP has been sent. In Immediate mode all feedback messages MAY be sent as reduced size RTCP. In early mode a feedback message scheduled for transmission as an Early RTCP, i.e not a Regular RTCP, MAY be sent as reduced size RTCP. All RTCP that are scheduled for transmission as Regular RTCP SHALL be sent as (full) compound RTCP as indicated by AVPF (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),” July 2006.) [RFC4585].
TOC |
A reduced size RTCP 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.
TOC |
TOC |
If an application is to use reduced size RTCP it is important to verify that they actually reach the session participants. As outlined above in Section 6.1 (Middle boxes) and Section 6.2 (Packet Validation) 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 reduced size RTCP.
The middle box issue is more difficult and here one will be required to use heuristics to determine if the reduced size RTCP are delivered or not. However in many cases the feedback messages sent using reduced size RTCP will result in either explicit or implicit indications that they have been received. Example of such are the RTP retransmission (Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” July 2006.) [RFC4588] that result from a NACK message (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),” July 2006.) [RFC4585], the Temporary Maximum Media Bitrate Notification message resulting from a Temporary Maximum Media Bitrate Request (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.) [RFC5104], or the presence of a Decoder Refresh Point (Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” February 2008.) [RFC5104] in the video media stream resulting from the Full Intra Request sent.
An algorithm to detect consistent failure of delivery of reduced size RTCP must be used by any application using it. The details of this algorithm is application dependent and therefore outside the scope of this document.
A method to detect if reduced size RTCP are discarded is to send a single SR packet in a lower layer datagram, then check that the timestamp is echoed back in the corresponding RR packet. This verification method is not completely 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.
TOC |
The result of the definition in Section 7.1 (Definition of non-compound RTCP) may be that the resulting size of reduced size RTCP can become larger than a normal compound RTCP. For applications that use access types that are sensitive to packet size (see Section 4.1 (Low birate links)) it is strongly RECOMMENDED that the use of reduced size RTCP is limited to the transmission of single RTCP in each lower layer datagram.
The methods to determine the need for this is outside the scope of this draft.
TOC |
As discussed earlier it is important that the transmission of compound RTCP 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] (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),” July 2006.). This as all regular RTCP must be full compound RTCP. Note that also in immediate mode is there a requirement on sending regular RTCP.
TOC |
Section 3.3 in RFC4585 gives the option to use AVPF Immediate mode as long as the groupsize is below a certain limit. As transmission using reduced size RTCP may become reduce the bandwidth demand it opens up for a more liberal use of immediate mode.
TOC |
We request to define the "a=rtcp-rsize" [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) attribute to indicate if the session participant is capable of supporting reduced size RTCP. It is a required that a participant that proposes the use of reduced size RTCP itself supports the reception of reduced size RTCP.
An offering client that wish to use reduced size RTCP MUST include the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is present in the offer SDP, the answerer that supports reduced size RTCP and wish to use it SHALL include the "a=rtcp-rsize" attribute in the answer.
TOC |
Following the guidelines in [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.), the IANA is requested to register one new SDP attribute:
This attribute defines the support for reduced size RTCP, i.e the possibility to transmit RTCP that does not conform 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.
TOC |
The security considerations of RTP (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] and AVPF (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),” July 2006.) [RFC4585] will apply also to reduced size RTCP. 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. This vulnerability can mostly be addressed by usage of any security mechanism that provide authentication, one example such mechanism is SRTP [RFC3711] (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.).
TOC |
The authors would like to thank all the people who gave feedback on this document.
This document also contain some text copied from [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.), (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),” July 2006.) [RFC4585]and (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711]. We take the opportunity to thank the authors of said documents.
TOC |
TOC |
[RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
[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 (TXT). |
TOC |
[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 (TXT). |
[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 (TXT). |
[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 (TXT). |
[RFC3711] | Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT). |
[RFC4566] | Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT). |
[RFC4588] | Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, “RTP Retransmission Payload Format,” RFC 4588, July 2006 (TXT). |
[RFC5104] | Wenger, S., Chandra, U., Westerlund, M., and B. Burman, “Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF),” RFC 5104, February 2008 (TXT). |
TOC |
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 |
TOC |
Copyright © 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.
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.