RFC 5104
Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
5. Congestion Control
The correct application of the AVPF [RFC4585] timing rules prevents the network from being flooded by feedback messages. Hence, assuming a correct implementation and configuration, the RTCP channel cannot break its bit rate commitment and introduce congestion. The reception of some of the feedback messages modifies the behaviour of the media senders or, more specifically, the media encoders.
Thus, modified behaviour MUST respect the bandwidth limits that the application of congestion control provides. For example, when a media sender is reacting to a FIR, the unusually high number of packets that form the decoder refresh point have to be paced in compliance with the congestion control algorithm, even if the user experience suffers from a slowly transmitted decoder refresh point. A change of the Temporary Maximum Media Stream Bit Rate value can only mitigate congestion, but not cause congestion as long as congestion control is also employed. An increase of the value by a request REQUIRES the media sender to use congestion control when increasing its transmission rate to that value. A reduction of the value results in a reduced transmission bit rate, thus reducing the risk for congestion.6. Security Considerations
The defined messages have certain properties that have security implications. These must be addressed and taken into account by users of this protocol. The defined setup signaling mechanism is sensitive to modification attacks that can result in session creation with sub-optimal configuration, and, in the worst case, session rejection. To prevent this type of attack, authentication and integrity protection of the setup signaling is required. Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications: a. severely reduced media bit rate due to false TMMBR messages that sets the maximum to a very low value; b. assignment of the ownership of a bounding tuple to the wrong participant within a TMMBN message, potentially causing unnecessary oscillation in the bounding set as the mistakenly identified owner reports a change in its tuple and the true owner possibly holds back on changes until a correct TMMBN message reaches the participants; c. sending TSTRs that result in a video quality different from the user's desire, rendering the session less useful; d. sending multiple FIR commands to reduce the frame rate, and make the video jerky, due to the frequent usage of decoder refresh points.
To prevent these attacks, there is a need to apply authentication and integrity protection of the feedback messages. This can be accomplished against threats external to the current RTP session using the RTP profile that combines Secure RTP [SRTP] and AVPF into SAVPF [SAVPF]. In the mixer cases, separate security contexts and filtering can be applied between the mixer and the participants, thus protecting other users on the mixer from a misbehaving participant.7. SDP Definitions
Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp- fb, that may be used to negotiate the capability to handle specific AVPF commands and indications, such as Reference Picture Selection, Picture Loss Indication, etc. The ABNF for rtcp-fb is described in section 4.2 of [RFC4585]. In this section, we extend the rtcp-fb attribute to include the commands and indications that are described for codec control in the present document. We also discuss the Offer/Answer implications for the codec control commands and indications.7.1. Extension of the rtcp-fb Attribute
As described in AVPF [RFC4585], the rtcp-fb attribute indicates the capability of using RTCP feedback. AVPF specifies that the rtcp-fb attribute must only be used as a media level attribute and must not be provided at session level. All the rules described in [RFC4585] for rtcp-fb attribute relating to payload type and to multiple rtcp- fb attributes in a session description also apply to the new feedback messages defined in this memo. The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type of the feedback message such as ack, nack, trr-int, and rtcp-fb-id. For example, to indicate the support of feedback of Picture Loss Indication, the sender declares the following in SDP v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Media with feedback t=0 0 c=IN IP4 host.example.com m=audio 49170 RTP/AVPF 98 a=rtpmap:98 H263-1998/90000 a=rtcp-fb:98 nack pli
In this document, we define a new feedback value "ccm", which
indicates the support of codec control using RTCP feedback messages.
The "ccm" feedback value SHOULD be used with parameters that indicate
the specific codec control commands supported. In this document, we
define four such parameters, namely:
o "fir" indicates support of the Full Intra Request (FIR).
o "tmmbr" indicates support of the Temporary Maximum Media Stream
Bit Rate Request/Notification (TMMBR/TMMBN). It has an
optional sub-parameter to indicate the session maximum packet
rate (measured in packets per second) to be used. If not
included, this defaults to infinity.
o "tstr" indicates support of the Temporal-Spatial Trade-off
Request/Notification (TSTR/TSTN).
o "vbcm" indicates support of H.271 Video Back Channel Messages
(VBCMs). It has zero or more subparameters identifying the
supported H.271 "payloadType" values.
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a
placeholder called rtcp-fb-id to define new feedback types. "ccm" is
defined as a new feedback type in this document, and the ABNF for the
parameters for ccm is defined here (please refer to section 4.2 of
[RFC4585] for complete ABNF syntax).
rtcp-fb-val =/ "ccm" rtcp-fb-ccm-param
rtcp-fb-ccm-param = SP "fir" ; Full Intra Request
/ SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
; Temporary max media bit rate
/ SP "tstr" ; Temporal-Spatial Trade-Off
/ SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
/ SP token [SP byte-string]
; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT
7.2. Offer-Answer
The Offer/Answer [RFC3264] implications for codec control protocol
feedback messages are similar to those described in [RFC4585]. The
offerer MAY indicate the capability to support selected codec
commands and indications. The answerer MUST remove all CCM
parameters corresponding to the CCMs that it does not wish to support
in this particular media session (for example, because it does not
implement the message in question, or because its application logic
suggests that support of the message adds no value). The answerer
MUST NOT add new ccm parameters in addition to what has been offered.
The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both sides have explicitly indicated as being supported. In other words, only the joint subset of CCM parameters from the offer and answer may be used. Note that including a CCM parameter in an offer or answer indicates that the party (offerer or answerer) is at least capable of receiving the corresponding CCM(s) and act upon them. In cases when the reception of a negotiated CCM mandates the party to respond with another CCM, it must also have that capability. Although it is not mandated to initiate CCMs of any negotiated type, it is generally expected that a party will initiate CCMs when appropriate. The session maximum packet rate parameter part of the TMMBR indication is declarative, and the highest value from offer and answer SHALL be used. If the session maximum packet rate parameter is not present in an offer, it SHALL NOT be included by the answerer.7.3. Examples
Example 1: The following SDP describes a point-to-point video call with H.263, with the originator of the call declaring its capability to support the FIR and TSTR/TSTN codec control messages. The SDP is carried in a high-level signaling protocol like SIP. v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Point-to-Point call c=IN IP4 192.0.2.124 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVPF 98 a=rtpmap:98 H263-1998/90000 a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm fir In the above example, when the sender receives a TSTR message from the remote party it is capable of adjusting the trade-off as indicated in the RTCP TSTN feedback message. Example 2: The following SDP describes a SIP end point joining a video mixer that is hosting a multiparty video conferencing session. The participant supports only the FIR (Full Intra Request) codec control command and it declares it in its session description.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir
When the video MCU decides to route the video of this participant, it
sends an RTCP FIR feedback message. Upon receiving this feedback
message, the end point is required to generate a full intra request.
Example 3: The following example describes the Offer/Answer
implications for the codec control messages. The offerer wishes to
support "tstr", "fir" and "tmmbr". The offered SDP is
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
The answerer wishes to support only the FIR and TSTR/TSTN messages
and the answerer SDP is
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
Example 4: The following example describes the Offer/Answer
implications for H.271 Video Back Channel Messages (VBCMs). The
offerer wishes to support VBCM and the sub-messages of payloadType 1
(one or more pictures that are entirely or partially lost) and 2 (a
set of blocks of one picture that are entirely or partially lost).
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 2
The answerer only wishes to support sub-messages of type 1 only
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1
So, in the above example, only VBCM indications comprised of
"payloadType" 1 will be supported.
8. IANA Considerations
The new value "ccm" has been registered with IANA in the "rtcp-fb"
Attribute Values registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters
Value name: ccm
Long Name: Codec Control Commands and Indications
Reference: RFC 5104
A new registry "Codec Control Messages" has been created to hold
"ccm" parameters located at time of publication at:
http://www.iana.org/assignments/sdp-parameters
New registration in this registry follows the "Specification required" policy as defined by [RFC2434]. In addition, they are required to indicate any additional RTCP feedback types, such as "nack" and "ack". The initial content of the registry is the following values: Value name: fir Long name: Full Intra Request Command Usable with: ccm Reference: RFC 5104 Value name: tmmbr Long name: Temporary Maximum Media Stream Bit Rate Usable with: ccm Reference: RFC 5104 Value name: tstr Long name: Temporal Spatial Trade Off Usable with: ccm Reference: RFC 5104 Value name: vbcm Long name: H.271 video back channel messages Usable with: ccm Reference: RFC 5104 The following values have been registered as FMT values in the "FMT Values for RTPFB Payload Types" registry located at the time of publication at: http://www.iana.org/assignments/rtp-parameters RTPFB range Name Long Name Value Reference -------------- --------------------------------- ----- --------- Reserved 2 [RFC5104] TMMBR Temporary Maximum Media Stream Bit 3 [RFC5104] Rate Request TMMBN Temporary Maximum Media Stream Bit 4 [RFC5104] Rate Notification The following values have been registered as FMT values in the "FMT Values for PSFB Payload Types" registry located at the time of publication at: http://www.iana.org/assignments/rtp-parameters
PSFB range Name Long Name Value Reference -------------- --------------------------------- ----- --------- FIR Full Intra Request Command 4 [RFC5104] TSTR Temporal-Spatial Trade-off Request 5 [RFC5104] TSTN Temporal-Spatial Trade-off Notification 6 [RFC5104] VBCM Video Back Channel Message 7 [RFC5104]9. Contributors
Tom Taylor has made a very significant contribution to this specification, for which the authors are very grateful, by helping rewrite the specification. Especially the parts regarding the algorithm for determining bounding sets for TMMBR have benefited.10. Acknowledgements
The authors would like to thank Andrea Basso, Orit Levin, and Nermeen Ismail for their work on the requirement and discussion document [Basso]. Versions of this memo were reviewed and extensively commented on by Roni Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni, Guido Franceschini, and others. The authors appreciate these reviews.11. References
11.1. Normative References
[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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.11.2. Informative References
[Basso] Basso, A., Levin, O., and N. Ismail, "Requirements for transport of video control commands", Work in Progress, October 2004. [AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC 14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG, JVT-G050, March 2003. [H245] ITU-T Rec. H.245, "Control protocol for multimedia communication", May 2006. [NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video Coding by Dynamic Replacing of Reference Pictures", in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996. [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996. [SAVPF] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Work in Progress, November 2007. [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003. [H.271] ITU-T Rec. H.271, "Video Back Channel Messages", June 2006.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC3261] 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. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [XML-MC] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", Work in Progress, November 2007.
Authors' Addresses
Stephan Wenger Nokia Corporation 975, Page Mill Road, Palo Alto,CA 94304 USA Phone: +1-650-862-7368 EMail: stewe@stewe.org Umesh Chandra Nokia Research Center 975, Page Mill Road, Palo Alto,CA 94304 USA Phone: +1-650-796-7502 Email: Umesh.1.Chandra@nokia.com Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: magnus.westerlund@ericsson.com Bo Burman Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: bo.burman@ericsson.com
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.