[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 3388

Internet Engineering Task Force                     Gonzalo Camarillo
Internet draft                                             Jan Holler
                                                    Goran AP Eriksson
                                                             Ericsson
                                                           April 2001
                                                 Expires October 2001
                                       <draft-ietf-mmusic-fid-01.txt>


                         The SDP fid attribute


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

   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.


Abstract

   This document defines an SDP media attribute. The use of this
   attribute allows receiving media from a single flow (several media
   streams), encoded in different formats during a particular session,
   in different ports and host interfaces.

















Camarillo/Holler/Eriksson                                            1


                        The SDP fid attribute



TABLE OF CONTENTS

   1   Motivation...................................................2
   1.1 SIP and cellular access......................................2
   1.2 DTMF tones...................................................3
   2   Media flow definition........................................3
   3   Flow identification attribute................................3
   4   Semantics of the fid attribute...............................4
   4.1 Interactions with other media level attributes...............4
   5   Usage of the fid attribute in SIP............................5
   5.1 Backward compatibility.......................................5
   5.2 Caller does not support fid..................................5
   5.3 Callee does not support fid..................................5
   6   Acknoledgements..............................................6
   7   References...................................................6
   8   Authors³ Addresses...........................................6


1. Motivation

   The RTSP RFC [1] defines a media stream as "a single media instance,
   e.g., an audio stream or a video stream as well as a single
   whiteboard or shared application group. When using RTP, a stream
   consists of all RTP and RTCP packets created by a source within an
   RTP session".

   This definition assumes that a single audio (or video) stream maps
   into an RTP session. The RTP RFC [2] defines an RTP session as
   follows: "For each participant, the session is defined by a
   particular pair of destination transport addresses (one network
   address plus a port pair for RTP and RTCP)".

   However, there are situations where a single media instance, (e.g.,
   an audio stream or a video stream) is sent using more than one RTP
   session. Two examples (among many others) of this kind of situation
   are cellular systems using SIP [3] and systems receiving DTMF tones
   on a different host than the voice.

1.1 SIP and cellular access

   Systems using a cellular access and SIP as a signalling protocol
   need to receive media over the air. During a session the media can
   be encoded using different codecs. The encoded media has to traverse
   the radio interface. The radio interface is generally characterized
   by being bit error prone and associated with relatively high packet
   transfer delays. In addition, radio interface resources in a
   cellular environment are scarce and thus expensive, which calls for
   special measures in providing a highly efficient transport [4]. In
   order to get an appropriate speech quality in combination with an
   efficient transport, precise knowledge of codec properties are
   required so that a proper radio bearer for the RTP session can be


Camarillo/Holler/Eriksson                                            2


                        The SDP fid attribute


   configured before transferring the media. These radio bearers are
   dedicated bearers per media type, i.e. codec.

   Cellular systems typically configure different radio bearers on
   different port numbers. Therefore, incoming media has to have
   different destination port numbers for the different possible codecs
   in order to be routed properly to the correct radio bearer. Thus,
   this is an example in which several RTP sessions are used to carry a
   single media instance (the encoded speech from the sender).

1.2 DTMF tones

   Some voice sessions include DTMF tones. Sometimes the voice handling
   is performed by a different host than the DTMF handling. [5]
   contains several examples of how application servers in the network
   gather DTMF tones for the user while the user receives the encoded
   speech on his user agent. In this situations it is necessary to
   establish two RTP sessions: one for the voice and the other for the
   DTMF tones. Both RTP sessions are logically part of the same media
   instance.

2. Media flow definition

   The previous examples show that the definition of a media stream in
   [1] has to be updated. It cannot be assumed that a single media
   instance maps into a single RTP session. Therefore, we introduce the
   definition of a media flow:

   Media flow consists of a single media instance, e.g., an audio
   stream or a video stream as well as a single whiteboard or shared
   application group. When using RTP, a media flow comprises one or
   more RTP sessions.

   For instance, in a two party call where the voice exchanged can be
   encoded using GSM or PCM, the receiver wants to receive GSM on a
   port number and PCM on a different port number. Two RTP sessions
   will be established, one carrying GSM and the other carrying PCM.

   At any particular moment just one codec is in use. Therefore, at any
   moment one of the RTP sessions will not transport any voice. Here
   the systems are dealing with a single media flow, but two RTP
   sessions.

3. Flow identification attribute

   An RTP session is described in SDP [6] using an "m" line. When a
   media flow comprises more than one RTP session, we need a way to
   associate several "m" lines together into a media flow.

   A new "flow identification" media attribute is defined. It is used
   for identifying media flows within a session. Its formatting in SDP
   is described by the following BNF:


Camarillo/Holler/Eriksson                                            3


                        The SDP fid attribute


         fid-attribute      = "a=fid:" identification-tag
         identification-tag = token

   The identification tag is unique within the SDP session description.

   Syntactically fid is a media-level attribute. It provides
   information about a media stream defined by an "m" line.
   Semantically fid would be defined as a session-level attribute since
   it provides flow hierarchy inside a session description.

4. Semantics of the fid attribute

   A media agent handling a media flow that comprises several "m" lines
   sends media to different destinations (IP address/port number)
   depending on the codec used at any moment. If several "m" lines
   contain the codec used media is sent to different destinations in
   parallel.

   For instance, a SIP user agent receives an INVITE with the following
   body:

         v=0
         o=Laura 289083124 289083124 IN IP4 second.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         m=audio 30000 RTP/AVP 0
         a=fid:1
         m=audio 30002 RTP/AVP 8
         a=fid:1
         m=audio 30004 RTP/AVP 0 8
         a=fid:1

   At a particular point of time, if the media agent is sending PCM u-
   law (payload 0) it sends RTP packets to ports 30000 and 30004 (first
   and third "m" lines). If it is sending PCM A-law (payload 8) it
   sends RTP packets to ports 30002 and 30004 (second and third "m"
   lines).

   Note that if several "m" lines with the same fid value contain the
   same codec the media agent MUST send media over several RTP sessions
   at the same time.

4.1 Interactions with other media level attributes

   Media level attributes affect a media stream defined by an "m" line.
   The presence of fid does not modify this behavior.

   For instance, a SIP user agent receives an INVITE with the following
   body:

         v=0
         o=Laura 289083124 289083124 IN IP4 second.example.com
         t=0 0

Camarillo/Holler/Eriksson                                            4


                        The SDP fid attribute


         c=IN IP4 131.160.1.112
         m=audio 30000 RTP/AVP 0
         a=fid:1
         m=audio 30002 RTP/AVP 8
         a=recvonly
         a=fid:1

   The media agent knows that at a certain moment it can send either
   PCM u-law to port number 30000 or PCM A-law to port number 30002.
   However, the media agent also knows that the other end will only
   send PCM u-law (payload 0).

   Note that the fid attribute allows to express uni-directional codecs
   for a bi-directional media flow, as it is shown in the example
   above.

5. Usage of the fid attribute in SIP

   SIP [3] is an application layer protocol for establishing,
   terminating and modifying multimedia sessions. SIP carries session
   descriptions in the bodies of the SIP messages but is independent
   from the protocol used for describing sessions. SDP [6] is one of
   the protocols that can be used for this purpose.

   Appendix B of [3] describes the usage of SDP in relation to SIP. It
   states: "The caller and callee align their media description so that
   the nth media stream ("m=" line) in the caller³s session description
   corresponds to the nth media stream in the callee³s description."

   The presence of the fid attribute in an SDP session description does
   not modify this behavior.

5.1 Backward compatibility

   This document does not define any SIP "Require" header. Therefore,
   if one of the SIP user agents does not understand the fid attribute
   the standard SDP fall back mechanism is used.

   A system that understands the fid attribute MUST add it to any SDP
   session description that it generates.

5.2 Caller does not support fid

   This situation does not represent a problem. The SDP in the INVITE
   will not contain any fid attribute. The callee knows that the caller
   does not support fid.

5.3 Callee does not support fid

   The callee will ignore the fid attribute, since it does not
   understand it. It will consider that the session comprises several
   media streams.


Camarillo/Holler/Eriksson                                            5


                        The SDP fid attribute


   Different implementations would behave in different ways.

   In the case of audio and different "m" lines for different codecs an
   implementation might decide to act as a mixer with the different
   incoming RTP sessions, which is the correct behavior.

   An implementation might also decide to refuse the request (e.g. 488
   Not acceptable here or 606 Not Acceptable) because it contains
   several "m" lines. In this case, the callee does not support the
   type of session that the caller wanted to establish. In case the
   caller is willing to establish a simpler session anyway, he should
   re-try the request without the fid attribute and only one "m" line
   per flow.

6. Acknowledgments

   The authors would like to thank Jonathan Rosenberg and Adam Roach
   for their feedback on this document.

7. References

   [1] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol
   (RTSP)", RFC 2326, IETF; April 1998.

   [2] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A
   Transport Protocol for Real-Time Applications", RFC 1889, IETF;
   January 1996.

   [3] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
   Session Initiation Protocol", RFC 2543, IETF; Mach 1999.

   [4] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access
   Networks", draft-westberg-realtime-cellular-03.txt, IETF; November
   2000. Work in progress.

   [5] J. Rosemberg/P.Mataga/H.Schulzrinne, "An Applcation Server
   Component Architecture for SIP", draft-rosenberg-sip-app-components-
   00.txt, IETF; November 2000. Work in progress.

   [6] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC
   2327, IETF; April 1998.

8. Authors³ Addresses

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland
   Phone: +358 9 299 3371
   Fax: +358 9 299 3052
   Email: Gonzalo.Camarillo@ericsson.com


Camarillo/Holler/Eriksson                                            6


                        The SDP fid attribute


   Jan Holler
   Ericsson Research
   S-16480 Stockholm
   Sweden
   Phone: +46 8 58532845
   Fax: +46 8 4047020
   Email: Jan.Holler@era.ericsson.se

   Goran AP Eriksson
   Ericsson Research
   S-16480 Stockholm
   Sweden
   Phone: +46 8 58531762
   Fax: +46 8 4047020
   Email: Goran.AP.Eriksson@era.ericsson.se







































Camarillo/Holler/Eriksson                                            7


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/