[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
SIPREC Working Group                                            C. Eckel
Internet-Draft                                                     Cisco
Intended status: Informational                        September 22, 2011
Expires: March 25, 2012


     Real-time Transport Protocol (RTP) Recommendations for SIPREC
                     draft-eckel-siprec-rtp-rec-02

Abstract

   This document provides recommendations and guidelines for RTP and
   RTCP in the context of SIPREC.  This document exists as a standalone
   document to facilitate discussion of the RTP recommendations, and it
   is anticipated that portions of this document will be incorporated
   into [I-D.ietf-siprec-protocol] rather than this document itself
   being adopted as a working group document.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 25, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Eckel                    Expires March 25, 2012                 [Page 1]


Internet-Draft               RTP-for-SIPREC               September 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Roles  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     4.1.  SRC acting as an RTP Translator  . . . . . . . . . . . . .  4
       4.1.1.  Forwarding Translator  . . . . . . . . . . . . . . . .  4
       4.1.2.  Transcoding Translator . . . . . . . . . . . . . . . .  4
     4.2.  SRC acting as an RTP Mixer . . . . . . . . . . . . . . . .  5
     4.3.  SRC acting as an RTP Endpoint  . . . . . . . . . . . . . .  5
   5.  RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  RTP Profile  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   7.  SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  CSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   9.  SDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     9.1.  CNAME  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   10. Keepalive  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   11. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . .  8
     11.1. Full Intra Request . . . . . . . . . . . . . . . . . . . .  8
       11.1.1. SIP INFO for FIR . . . . . . . . . . . . . . . . . . .  9
     11.2. Picture Loss Indicator . . . . . . . . . . . . . . . . . .  9
     11.3. Temporary Maximum Media Stream Bit Rate Request  . . . . .  9
       11.3.1. Renegotiation of SDP bandwidth attribute . . . . . . .  9
   12. Symmetric RTP/RTCP for Sending and Receiving . . . . . . . . .  9
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     16.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
















Eckel                    Expires March 25, 2012                 [Page 2]


Internet-Draft               RTP-for-SIPREC               September 2011


1.  Introduction

   This document provides recommendations and guidelines for RTP and
   RTCP in the context of SIPREC.  In order to communicate most
   effectively, the Session Recording Client (SRC) and the Session
   Recording (SRS) SHOULD utilize the mechanisms provided by RTP in a
   well defined and predicable manner.  It is the goal of this document
   to make the reader aware of these mechanisms and provide
   recommendations and guidelines.

   This document exists as a standalone document to facilitate
   discussion of the RTP recommendations, and it is anticipated that
   portions of this document will be incorporated into
   [I-D.ietf-siprec-protocol] rather than this document itself being
   adopted as a working group document.  This document makes use of
   normative language as it is expected to exist within the working
   group document into which it is eventually incorporated.


2.  Terminology

   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 [RFC2119].


3.  Definitions

   This document uses the definitions provided in
   [I-D.ietf-siprec-architecture] for all SIPREC modules.  A Session
   Recording Client (SRC), as defined within SIPREC, is expected to
   implement one or more of a variety of RTP roles within the context of
   various SIPREC use cases.  These roles include, but are not limited
   to, acting as an end system, a mixer, or a translator.  This document
   uses the definitions provided in "RTP: A Transport Protocol for Real-
   Time Application" [RFC3550].


4.  Roles

   An SRC has the task of gathering media from the various UAs in a CS
   and forwarding the information to the SRS within the context of an
   RS.  There are numerous ways in which an SRC may do this is,
   including appearing as one of the UAs within a CS, or as a B2BUA
   between UAs within a CS.






Eckel                    Expires March 25, 2012                 [Page 3]


Internet-Draft               RTP-for-SIPREC               September 2011


                       UA <-- CS --> SRC <-- RS --> SRS

                            Figure 1: UA as SRC


                                     SRS
                                      ^
                                      |
                                     RS
                                      |
                                      v
                      UA1 <-- CS --> SRC <-- CS --> UA2

                          Figure 2: B2BUA as SRC

   The following subsections define a set of roles an SRC may choose to
   play based on its position with respect to a UA within a CS, and an
   SRS within an RS.

4.1.  SRC acting as an RTP Translator

   The SRC may act as a translator, as defined in [RFC3550].  A defining
   characteristic of a translator is that it forwards RTP packets with
   their SSRC identifier intact.  There are two types of translators,
   one that simply forward, and another that performs transcoding (e.g.,
   from one codec to another) in addition to forwarding.

4.1.1.  Forwarding Translator

   When acting as a forwarding translator, RTP received as separate
   streams from different sources (e.g., from different UAs with
   different SSRCs) cannot be mixed by the SRC and MUST be sent
   separately to the SRS.  All RTCP reports MUST be passed by the SRC
   between the UAs and the SRS, such that the UAs and SRS are able to
   detect any SSRC collisions.

   RTCP Sender Reports generated by a UA sending a stream MUST be
   forwarded to the SRS.  RTCP Receiver Reports generated by the SRS
   MUST be forwarded to the relevant UA.

   If SRTP is used on both the CS and the RS, decryption and/or re-
   encryption may occur.  For example, if different keys are used, it
   will occur.  If the same keys are used, it need not occur.

4.1.2.  Transcoding Translator

   When acting as a transcoding translator, an SRC MAY perform
   transcoding (e.g., from one codec to another), and this may result in



Eckel                    Expires March 25, 2012                 [Page 4]


Internet-Draft               RTP-for-SIPREC               September 2011


   a different rate of packets between what the SRC receives and what
   the sends.  As when acting as a forwarding translator, RTP received
   as separate streams from different sources (e.g., from different UAs
   with different SSRCs) cannot be mixed by the SRC and MUST be sent
   separately to the SRS.  All RTCP reports MUST passed by the SRC
   between the UAs and the SRS, such the UAs and SRS they are able to
   detect any SSRC collisions.

   RTCP Sender Reports generated by a UA sending a stream MUST be
   forwarded to the SRS.  RTCP Receiver Reports generated by the SRS
   MUST be forwarded to the relevant UA.  The SRC may need to manipulate
   the RTCP Receiver Reports to take account of any transcoding that has
   taken place.

   If SRTP is used on both the CS and the RS, decryption and/or re-
   encryption may occur.  For example, if different keys are used, it
   will occur.  If the same keys are used, it need not occur.

4.2.  SRC acting as an RTP Mixer

   In the case of the SRC acting as a RTP mixer, as defined in
   [RFC3550], the SRC combines RTP streams from different UA and sends
   them towards the SRS using its own SSRC.  The SSRCs from the
   contributing UA SHOULD be conveyed as CSRCs identifiers within this
   stream.  The SRC may make timing adjustments among the received
   streams and generate its own timing on the stream sent to the SRS.
   Optionally an SRC acting as a mixer can perform transcoding, and can
   even cope with different codings received from different UAs.  RTCP
   Sender Reports and Receiver Reports are not forwarded by an SRC
   acting as mixer, but there are requirements for forwarding RTCP
   Source Description (SDES) packets.  The SRC generates its own RTCP
   Sender and Receiver reports toward the associated UAs and SRS.  The
   use of SRTP between the SRC and the SRS for the RS is independent of
   the use of SRTP between the UAs and SRC for the CS.

4.3.  SRC acting as an RTP Endpoint

   The case of the SRC acting as an RTP endpoint, as defined in
   [RFC3550], is similar to the mixer case, except that the RTP session
   between the SRC and the SRS is considered completely independent from
   the RTP session that is part of the CS.  The SRC can, but need not,
   mix RTP streams from different participants prior to sending to the
   SRS.  RTCP between the SRC and the SRS is completely independent of
   RTCP on the CS.  The use of SRTP between the SRC and the SRS is
   independent of the use of SRTP on the CS.






Eckel                    Expires March 25, 2012                 [Page 5]


Internet-Draft               RTP-for-SIPREC               September 2011


5.  RTCP

   The RTP data transport is augmented by a control protocol (RTCP) to
   allow monitoring of the data delivery.  RTCP, as defined in
   [RFC3550], is based on the periodic transmission of control packets
   to all participants in the RTP session, using the same distribution
   mechanism as the data packets.  Support for RTCP is REQUIRED, per
   [RFC3550], and it provides, among other things, the following
   important functionality in relation to SIPREC:

   1) Feedback on the quality of the data distribution.  This feedback
   is important for flow and congestion control functions, and to get
   feedback from the receivers to diagnose faults in the distribution.
   As such, RTCP is a well defined and efficient mechanism for the SRS
   to inform the SRC or any issues that arise in the reception of media
   that is to be recorded.

   2) Carries a persistent transport-level identifier for an RTP source
   called the canonical name or CNAME.  The SSRC identifier may change
   if a conflict is discovered or a program is restarted; in which case
   receivers can use the CNAME to keep track of each participant.
   Receivers may also use the CNAME to associate multiple data streams
   from a given participant in a set of related RTP sessions, for
   example to synchronize audio and video.  Synchronization of media
   streams is also facilitated by the NTP and RTP timestamps included in
   RTCP packets by data senders.


6.  RTP Profile

   The RECOMMENDED RTP profiles for both the SRC and SRS are "Extended
   Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-
   Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP
   streams, and "Extended RTP Profile for Real-time Transport Control
   Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non
   encrypted media streams.  However, as this is not a requirement, some
   implementations may use "The Secure Real-time Transport Protocol
   (SRTP)", [RFC3711] and "RTP Profile for Audio and Video Conferences
   with Minimal Control", AVP [RFC3551].  Therefore, it is RECOMMENDED
   that the SRC and SRS not rely entirely on SAVPF or AVPF for core
   functionality that may be at least partially achievable using SAVP
   and AVP.

   AVPF and SAVPF provide an improved RTCP timer model that allows more
   flexible transmission of RTCP packets as response to events, rather
   than strictly according to bandwidth.  AVPF based codec control
   messages provide efficient mechanisms for an SRC and SRS to handle
   events such as scene changes, error recovery, and dynamic bandwidth



Eckel                    Expires March 25, 2012                 [Page 6]


Internet-Draft               RTP-for-SIPREC               September 2011


   adjustments.  These messages are discussed in more detail later in
   this document.

   SAVP and SAVPF provide media encryption, integrity protection, replay
   protection, and a limited form of source authentication.  They do not
   contain or require a specific keying mechanism.


7.  SSRC

   The synchronization source (SSRC), as defined in [RFC3550], is
   carried in the RTP header and in various fields of RTCP packets.  It
   is a random 32-bit number that is required to be globally unique
   within an RTP session.  It is crucial that the number be chosen with
   care in order that participants on the same network or starting at
   the same time are not likely to choose the same number.  Guidelines
   regarding SSRC value selection and conflict resolution are provided
   in [RFC3550].

   The SSRC may also be used to separate different sources of media
   within a single RTP session.  For this reason as well as for conflict
   resolution, it is important that the SRC and SRS handle changes in
   SSRC values and properly identify the reason of the change.  The
   CNAME values carried in RTCP facilitate this identification.


8.  CSRC

   The contributing source (CSRC), as defined in [RFC3550], identifies
   the source of a stream of RTP packets that has contributed to the
   combined stream produced by an RTP mixer.  The mixer inserts a list
   of the SSRC identifiers of the sources that contributed to the
   generation of a particular packet into the RTP header of that packet.
   This list is called the CSRC list.  It is RECOMMENDED that a SRC,
   when acting a mixer, sets the CSRC list accordingly, and that the SRS
   interprets the CSRC list appropriately when received.


9.  SDES

   The Source Description (SDES), as defined in [RFC3550], contains an
   SSRC/CSRC identifier followed by a list of zero or more items, which
   carry information about the SSRC/CSRC.  End systems send one SDES
   packet containing their own source identifier (the same as the SSRC
   in the fixed RTP header).  A mixer sends one SDES packet containing a
   chunk for each contributing source from which it is receiving SDES
   information, or multiple complete SDES packets if there are more than
   31 such sources.



Eckel                    Expires March 25, 2012                 [Page 7]


Internet-Draft               RTP-for-SIPREC               September 2011


9.1.  CNAME

   The Canonical End-Point Identifier (CNAME), as defined in [RFC3550],
   provides the binding from the SSRC identifier to an identifier for
   the source (sender or receiver) that remains constant.  It is
   important the an SRC and SRS generate CNAMEs appropriately and use
   them for this purpose.  Guidelines for generating CNAME values are
   provided in "Guidelines for Choosing RTP Control Protocol (RTCP)
   Canonical Names (CNAMEs)" [RFC6222].


10.  Keepalive

   It is anticipated that media streams in SIPREC may exist in inactive
   states for extended periods of times for an of a number of valid
   reasons.  In order for the bindings and any pinholes in NATs/
   firewalls to remain active during such intervals, it is RECOMMENDED
   to follow the keep-alive procedure recommended in "Application
   Mechanism for Keeping Alive the NAT Mappings Associated to RTP/RTP
   Control Protocol (RTCP) Flows" [RFC6263] for all RTP media streams.


11.  RTCP Feedback Messages

   "Codec Control Messages in the RTP Audio-Visual Profile with Feedback
   (AVPF)" [RFC5104] specifies extensions to the messages defined in
   AVPF [RFC4585].  Support for and proper usage of these messages is
   important to SRC and SRS implementations.  Note that these messages
   are applicable only when using the AVFP or SAVPF RTP profiles.

11.1.  Full Intra Request

   A Full Intra Request (FIR) Command, when received by the designate
   media sender, requires that the media sender sends a Decoder Refresh
   Point at the earliest opportunity.  Using a decoder refresh point
   implies refraining from using any picture sent prior to that point as
   a reference for the encoding process of any subsequent picture sent
   in the stream.

   Decoder refresh points, especially Intra or IDR pictures for H.264
   video codecs, are in general several times larger in size than
   predicted pictures.  Thus, in scenarios in which the available bit
   rate is small, the use of a decoder refresh point implies a delay
   that is significantly longer than the typical picture duration.







Eckel                    Expires March 25, 2012                 [Page 8]


Internet-Draft               RTP-for-SIPREC               September 2011


11.1.1.  SIP INFO for FIR

   "XML Schema for Media Control" [RFC5168] defines an Extensible Markup
   Language (XML) Schema for video fast update.  Implementations are
   discouraged from using the method described except for backward
   compatibility purposes.  Implementations SHOULD use FIR messages
   instead.

11.2.  Picture Loss Indicator

   Picture Loss Indication (PLI), as defined in [RFC4585], informs the
   encoder of the loss of an undefined amount of coded video data
   belonging to one or more pictures.  Using the FIR command to recover
   from errors is explicitly disallowed, and instead the PLI message
   SHOULD be used.  FIR SHOULD be used only in situations where not
   sending a decoder refresh point would render the video usable for the
   users.  Examples where sending FIR is appropriate include a
   multipoint conference when a new user joins the conference and no
   regular decoder refresh point interval is established, and a video
   switching MCU that changes streams.

11.3.  Temporary Maximum Media Stream Bit Rate Request

   A receiver, translator, or mixer uses the Temporary Maximum Media
   Stream Bit Rate Request (TMMBR) to request a sender to limit the
   maximum bit rate for a media stream to the provided value.
   Appropriate use of TMMBR facilitates rapid adaptation to changes in
   available bandwidth.

11.3.1.  Renegotiation of SDP bandwidth attribute

   If it is likely that the new value indicated by TMMBR will be valid
   for the remainder of the session, the TMMBR sender is expected to
   perform a renegotiation of the session upper limit using the session
   signaling protocol.  Therefore for SIPREC, implementations are
   RECOMMENDED to use TMMBR for temporary changes, and renegotiation of
   bandwidth via SDP offer/answer of more permanent changes.


12.  Symmetric RTP/RTCP for Sending and Receiving

   Within an SDP offer/answer exchange, RTP entities choose the RTP and
   RTCP transport addresses (i.e., IP addresses and port numbers) on
   which to receive packets.  When sending packets, the RTP entities may
   use the same source port or a different source port as those signaled
   for receiving packets.  When the transport address used to send and
   receive RTP is the same, it is termed "symmetric RTP" [RFC4961].
   Likewise, when the transport address used to send and receive RTCP is



Eckel                    Expires March 25, 2012                 [Page 9]


Internet-Draft               RTP-for-SIPREC               September 2011


   the same, it is termed "symmetric RTCP" [RFC4961].

   When sending RTP, it is REQUIRED to use symmetric RTP.  When sending
   RTCP, it is REQUIRED to use symmetric RTCP.  Although an SRS will not
   normally send RTP, it will send RTCP as well as receive RTP and RTCP.
   Likewise, although an SRC will not normally receive RTP, it will
   receive RTCP as well as send RTP and RTCP.

      Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP
      multiplexing [RFC5761].


13.  Security Considerations

   In many scenarios it will be critical that the media transported
   between the SRC and SRS using RTP/RTCP be protected.  Media
   encryption is an important element of the overall SIPREC solution.
   The details regarding the encryption of the RTP/RTCP media will be
   addressed in [I-D.ietf-siprec-protocol].


14.  IANA Considerations

   None.


15.  Acknowledgements

   Thank you to Andrew Hutton, Ram Mohan, and Muthu Perumal, John
   Elwell, and Dan Wing for their valuable contributions.


16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

16.2.  Informative References

   [I-D.ietf-siprec-architecture]
              Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
              Architecture for Media Recording using the Session
              Initiation Protocol", draft-ietf-siprec-architecture-02
              (work in progress), April 2011.

   [I-D.ietf-siprec-protocol]



Eckel                    Expires March 25, 2012                [Page 10]


Internet-Draft               RTP-for-SIPREC               September 2011


              Portman, L., Lum, H., Johnston, A., and A. Hutton,
              "Session Recording Protocol",
              draft-ietf-siprec-protocol-00 (work in progress),
              August 2011.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [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.

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, July 2007.

   [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.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, February 2008.

   [RFC5168]  Levin, O., Even, R., and P. Hagendorf, "XML Schema for
              Media Control", RFC 5168, March 2008.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

   [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", RFC 6222, April 2011.

   [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
              Keeping Alive the NAT Mappings Associated with RTP / RTP
              Control Protocol (RTCP) Flows", RFC 6263, June 2011.





Eckel                    Expires March 25, 2012                [Page 11]


Internet-Draft               RTP-for-SIPREC               September 2011


Author's Address

   Charles Eckel
   Cisco
   170 West Tasman Drive
   San Jose, CA 95134
   United States

   Email: eckelcu@cisco.com










































Eckel                    Expires March 25, 2012                [Page 12]