tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5104

 
 
 

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

Part 4 of 4, p. 52 to 64
Prev RFC Part

 


prevText      Top      Up      ToC       Page 52 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.