Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5104

Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)

Pages: 64
Proposed Standard
Updated by:  77288082
Part 4 of 4 – Pages 52 to 64
First   Prev   None

Top   ToC   RFC5104 - Page 52   prevText

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.
Top   ToC   RFC5104 - Page 53
   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.
Top   ToC   RFC5104 - Page 54
   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
Top   ToC   RFC5104 - Page 55
   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.
Top   ToC   RFC5104 - Page 56
   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.
Top   ToC   RFC5104 - Page 57
         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
Top   ToC   RFC5104 - Page 58
   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
Top   ToC   RFC5104 - Page 59
   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
Top   ToC   RFC5104 - Page 60
   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.
Top   ToC   RFC5104 - Page 61
   [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.
Top   ToC   RFC5104 - Page 62
   [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.
Top   ToC   RFC5104 - Page 63

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
Top   ToC   RFC5104 - Page 64
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.