Internet Engineering Task Force                     Gonzalo Camarillo
Internet draft                                             Jan Holler
                                                    Goran AP Eriksson
                                                             Ericsson
                                                            July

                                                  Henning Schulzrinne
                                                  Columbia University

                                                          August 2001
                                                Expires January February 2002
                                       <draft-ietf-mmusic-fid-03.txt>
                                       <draft-ietf-mmusic-fid-04.txt>

                     Grouping of media lines in SDP

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 two SDP attributes: "group" and "mid". They
   allow to group together several "m" lines for two different
   purposes: for lip synchronization and for 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

Camarillo/Holler/Eriksson/Schulzrinne                                1
                    Grouping of media lines in SDP

TABLE OF CONTENTS

   1     Terminology................................................2     Introduction...............................................2
   2     Terminology................................................3
   3     Media stream identification attribute......................2
   3     Group attribute............................................2 attribute......................3
   4     Group attribute............................................3
   5     Use of "group" and "mid"...................................3
   6     Lip Synchronization (LS)...................................3
   5 (LS)...................................4
   6.1   Example of LS..............................................4
   7     Flow Identification (FID)..................................3
   5.1 (FID)..................................5
   7.1   SIP and cellular access....................................4
   5.2 access....................................5
   7.2   DTMF tones.................................................4
   5.3 tones.................................................5
   7.3   Media flow definition......................................5
   5.4 definition......................................6
   7.4   FID semantics..............................................5
   5.4.1 Interactions semantics..............................................6
   7.4.1 Examples of "group" with other media level attributes..6
   5.4.2 Media in parallel..........................................7
   5.4.3 DTMF tones encoded as telephony events.....................8
   6 FID............................................6
   8     Scenarios that FID does not cover..........................9
   8.1   Parallel encoding using different codecs...................9
   8.2   Layered encoding..........................................10
   8.3   Same IP address and port number...........................10
   9     Usage of the "group" attribute in SIP......................8
   6.1   Media alignment............................................9
   6.2 SIP.....................11
   9.1   Mid value in responses.....................................9
   6.3 responses....................................11
   9.1.1 Example...................................................11
   9.2   Group value in responses...................................9
   6.4 responses..................................12
   9.2.1 Example...................................................13
   9.3   Capability negotiation....................................14
   9.3.1 Example...................................................14
   9.4   Backward compatibility....................................10
   6.4.1 compatibility....................................14
   9.4.1 Client does not support "group"...........................11
   6.4.2 "group"...........................15
   9.4.2 Server does not support "group"...........................11
   7     Acknoledgements...........................................11
   8     References................................................11
   9 "group"...........................15
   10    IANA considerations.......................................15
   11    Acknowledgements..........................................15
   12    References................................................15
   13    Authors³ Addresses........................................12 Addresses........................................16

1 Introduction

   An SDP session description typically contains a number (one or more)
   of media lines - they are commonly known as "m" lines. When a
   session description contains more than one "m" line, SDP does not
   provide any means to express a particular relationship between two
   or more of them. When an application receives an SDP session
   description with more than one "m" line it is up to the application
   what to do with them. SDP does not carry any information about
   grouping media streams.

   While in some environments this information can be carried out of
   band, it would be desirable to have extensions to SDP that allowed
   to express how different media streams within a session description
   relate to each other. This document defines such extensions.

Camarillo/Holler/Eriksson/Schulzrinne                                2
                    Grouping of media lines in SDP

2 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]
   and indicate requirement levels for compliant implementations.

2.

3. Media stream identification attribute

   A new "media stream identification" media attribute is defined. It
   is used for identifying media streams within a session description.
   Its formatting in SDP [2] is described by the following BNF:

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

   The identification tag MUST be unique within the an SDP session
   description.

3.

4. Group attribute

   A new "group" session level attribute is defined. It is used for
   grouping together different media streams. Its formatting in SDP is
   described by the following BNF:

Camarillo/Holler/Eriksson                                            2
                    Grouping of media lines in SDP

         group-attribute    = "a=group:" semantics
                              2*(space
                              *(space identification-tag)
         semantics          = "LS" | "FID"

   This document defines two standard semantics: LS (Lip
   Synchronization) and FID (Flow Identification). If in the future it
   was needed to standardize further semantics they would need to be
   defined in a standards track document. However, defining new
   semantics apart from LS and FID is discouraged. Instead, it is
   RECOMMENDED to use other session description mechanisms such as
   SDPng [3].

   There MAY be several "a=group"

5. Use of "group" and "mid"

   All the "m" lines in of a session description.

   "a=group" lines that contain identification-tags description that are uses "group" MUST be
   identified with an "mid" attribute regardless of whether they appear
   or not
   present in the group line(s). If a session description MUST be simply ignored. The
   application acts as if the "a=group" contains at
   least one "m" line did not exist.

4. Lip Synchronization (LS)

   The play out of media streams that are grouped together using LS
   semantics MUST has no "mid" identification the application
   MUST NOT perform any grouping of media lines.

   "a=group" lines are used to group together several "m" lines that
   are identified by their "mid" attribute. "a=group" lines that
   contain identification-tags that do not correspond to any "m" line
   within the session description MUST be synchronized. simply ignored. The
   application acts as if the "a=group" line did not exist. The
   behavior of an application receiving an SDP with grouped "m" lines
   is defined by the semantics field in the "a=group" line.

Camarillo/Holler/Eriksson/Schulzrinne                                3
                    Grouping of media lines in SDP

   There MAY be several "a=group" lines in a session description.

   An application that wants to be compliant to this specification MUST
   support both "group" and "mid". An application that supported just
   one of them would not be compliant.

6. Lip Synchronization (LS)

   An application that receives a session description that contains "m"
   lines that are grouped together using LS semantics MUST synchronize
   the play out of the corresponding media streams. Note that LS
   semantics not only apply to a video stream that has to be
   synchronized with an audio stream. The play out of two streams of
   the same type can perfectly be synchronized as well.

   For RTP streams synchronization is typically performed using RTCP,
   which provides enough information to map time stamps from the
   different streams into a wall clock. However, the concept of media
   stream synchronization MAY also apply to media streams that do not
   make use of RTP. If this is the case, the application MUST recover
   the original timing relationship between the streams using whatever
   available mechanism.

6.1 Example of LS

   The following example shows a session description where of a conference
   that is being multicast. The first media stream (mid:1) contains the audio
   and
   voice of the speaker, who speaks in English. The second media stream
   (mid:2) contains the video component and the third (mid:3) media
   stream have carries the translation to be synchronized.

         v=0
         o=Laura Spanish of what he is saying. The
   first and the second media streams MUST be synchronized.

         v=0
         o=Laura 289083124 289083124 IN IP4 first.example.com one.example.com
         t=0 0
         c=IN IP4 131.160.1.112 224.2.17.12/127
         a=group:LS 1 2
         m=audio 30000 RTP/AVP 0
         a=mid:1
         m=video 30002 RTP/AVP 31
         a=mid:2
         m=audio 30004 RTP/AVP 0
         i=This media stream contains the Spanish translation
         a=mid:3

   Note that although the third media stream is not present in the
   group line it still contains an mid attribute (mid:3). All the "m"
   lines of a session description that uses "group" MUST be identified
   with contain an "mid" mid attribute regardless (mid:3), as stated
   before.

Camarillo/Holler/Eriksson/Schulzrinne                                4
                    Grouping of whether they appear or not media lines in
   the group line(s).

5. SDP

7. Flow Identification (FID)

   An "m" line in an SDP session description defines a media stream.
   However, SDP does not define what a media stream is. To find the

Camarillo/Holler/Eriksson                                            3
                    Grouping of media lines in SDP
   definition of a media stream we have to go to the RTSP
   specification. The RTSP RFC [4] 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. To find the definition of an RTP session we go
   to the RTP specification. The RTP RFC [5] 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)".

   While the previous definitions cover the most common cases, 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 [6] and systems receiving DTMF tones on a
   different host than the voice.

5.1

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

5.2

7.2 DTMF tones

   Some voice sessions include DTMF tones. Sometimes the voice handling
   is performed by a different host than the DTMF handling. [8]
   contains several examples of how application servers in the network

Camarillo/Holler/Eriksson/Schulzrinne                                5
                    Grouping of media lines in SDP

   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

Camarillo/Holler/Eriksson                                            4
                    Grouping of media lines in SDP
   DTMF tones. Both RTP sessions are logically part of the same media
   instance.

5.3

7.3 Media flow definition

   The previous examples show that the definition of a media stream in
   [4] do not cover some scenarios. 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.

5.4

7.4 FID semantics

   Several "m" lines grouped together using FID semantics form a media
   flow. A media agent handling a media flow that comprises several "m"
   lines sends MUST send a copy of the media to different destinations (IP address/port number)
   depending on every "m" line part of the
   flow as long as the codecs and the direction attribute present in a
   particular "m" line allow it.

   It is assumed that the application uses only one codec used at any moment.

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

         v=0
         o=Laura 289083124 289083124 IN IP4 second.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 3
         a=rtpmap:3 GSM/8000
         a=mid:1
         m=audio 30002 RTP/AVP 97
         a=rtpmap:97 AMR/8000
         a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-
      neighbor; maxframes=1
         a=mid:2 media produced. This would be codec MAY change dynamically during
   the session, but at any certain moment only one codec is in use.

   The application encodes the media using the current codec and checks
   one by one all the "m" lines that are part of the flow. If a
   particular "m" line contains the codec being used and the direction
   attribute is "sendonly" or "sendrecv" a copy of the encoded media is
   sent to the address/port specified in that particular media stream.
   If either the "m" line does not contain the codec being used or the
   direction attribute is neither "sendonly" nor "sendrecv" nothing is
   sent over this media stream.

   The application typically ends up sending media to different
   destinations (IP address/port number) depending on the codec used at
   any moment.

7.4.1 Examples of FID

   The session description below would be the SDP sent by a terminal SIP user
   agent using a cellular access. The terminal user agent supports GSM on port
   30000 and AMR on port 30002. When the remote party sends GSM it will
   send RTP packets to port number 30000. When AMR is the codec chosen,
   packets will be sent to port

Camarillo/Holler/Eriksson                                            5
                    Grouping of media lines in SDP 30002. Note that the remote party can
   switch between both codecs dynamically in the middle of the session.
   However, in this example, only one media stream at a time carries

Camarillo/Holler/Eriksson/Schulzrinne                                6
                    Grouping of media lines in SDP

   voice. The other remains "muted" while its corresponding codec is
   not in use.

         v=0
         o=Laura 289083124 289083124 IN IP4 two.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 3
         a=rtpmap:3 GSM/8000
         a=mid:1
         m=audio 30002 RTP/AVP 97
         a=rtpmap:97 AMR/8000
         a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-
      neighbor; maxframes=1
         a=mid:2

   In the previous example a system receives media on the same IP
   address on different port numbers. The following example shows how a
   system can receive different codecs on different IP addresses.

         v=0
         o=Laura 289083124 289083124 IN IP4 third.example.com three.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 20000 RTP/AVP 0
         c=IN IP4 131.160.1.111
         a=rtpmap:0 PCMU/8000
         a=mid:1
         m=audio 30002 RTP/AVP 97
         a=rtpmap:97 AMR/8000
         a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change-
      neighbor; maxframes=1
         a=mid:2

   The cellular terminal of this example only supports the AMR codec.
   However, many current IP phones only support PCM (payload 0). In
   order to be able to interoperate with them, the cellular terminal
   uses a transcoder whose IP address is 131.160.1.111. The cellular
   terminal includes in its SDP support for PCM at that IP address.
   Remote systems will send AMR directly to the terminal but PCM will
   be sent to the transcoder. The transcoder will be configured (using
   whatever method) to convert the incoming PCM audio to AMR and send
   it to the terminal.

5.4.1 Interactions of

   The next example shows that the "group" attribute used with other media level attributes

   Media level attributes affect FID
   semantics allows to express uni-directional codecs for a bi-
   directional media stream defined by an "m" line.
   The presence of "group" does not modify this behavior.

   This property can be flow. That is, a codec that is only used for different purposes. The example below
   shows in one possible use
   direction within a sendrecv media stream.

Camarillo/Holler/Eriksson/Schulzrinne                                7
                    Grouping of this. A SIP user agent receives an INVITE
   with the following body: media lines in SDP

         v=0
         o=Laura 289083124 289083124 IN IP4 forth.example.com four.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 0
         a=mid:1
         m=audio 30002 RTP/AVP 8
         a=recvonly
         a=mid:2

Camarillo/Holler/Eriksson                                            6
                    Grouping of media lines in SDP

   The media

   A user agent that receives the SDP above knows that at a certain
   moment it can send either PCM u-law to port number 30000 or PCM A-law 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 "group" attribute used with FID semantics allows to
   express uni-directional codecs for a bi-directional media flow, as
   it is shown in the

   The following example above.

5.4.2 Media in parallel

   It can happen that shows a session description with different "m"
   lines grouped together using FID semantics that contain the same
   codec. The SDP below shows one example of
   this situation:

         v=0
         o=Laura 289083124 289083124 IN IP4 fifth.example.com five.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=groupe:FID 1 2 3
         m=audio 30000 RTP/AVP 0
         a=mid:1
         m=audio 30002 RTP/AVP 8
         a=mid:2
         m=audio 20000 RTP/AVP 0 8
         c=IN IP4 131.160.1.111
         a=recvonly
         a=mid:3

   If several "m" lines contain the codec used at a certain point of
   time media MUST be sent to different destinations in parallel.

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

   The system that generated the SDP above supports PCM u-law on port
   30000 and PCM A-law on port 30002. Besides, it uses an application
   server whose IP address is 131.160.1.111 that records all the
   conversation. That is why the application server always receives a
   copy of the audio stream regardless of the codec being used at any
   given moment (it receives both u-law and A-law).

   Note actually performs an RTP dump, so it can
   effectively receive any codec).

   Remember that if several "m" lines grouped together using FID
   semantics contain the same codec the media agent MUST send media
   over several RTP sessions at the same time.

Camarillo/Holler/Eriksson                                            7

Camarillo/Holler/Eriksson/Schulzrinne                                8
                    Grouping of media lines in SDP

5.4.3

   The last example of this section deals with DTMF tones encoded as telephony events tones. DTMF tones
   can be transmitted using a regular voice codec or can be transmitted
   as telephony events. The RTP payload for DTMF tones treated as
   telephone events is described in RFC 2833 [9]. Below there is an
   example of an SDP session description using FID semantics and this
   payload type.

         v=0
         o=Laura 289083124 289083124 IN IP4 sixth.example.com six.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 0
         a=mid:1
         m=audio 20000 RTP/AVP 97
         c=IN IP4 131.160.1.111
         a=rtpmap:97 telephone-events
         a=mid:2

   The remote party would send PCM encoded voice (payload 0) to
   131.160.1.112 and DTMF tones encoded as telephony events to
   131.160.1.111. Note that only voice or DTMF is sent at a particular
   point of time. When DTMF tones are sent the first media stream does
   not carry any data and when voice is sent there is no data in the
   second media stream. FID semantics provide different destinations
   for alternative codecs.

8 Scenarios that FID does not cover

   It is worthwhile mentioning some scenarios where the "group"
   attribute using existing semantics (particularly FID) might seem to
   be applicable but it is not. This section has been included because
   we have observed some confusion within the community regarding the
   three scenarios described below. This section helps clarify them.

8.1 Parallel encoding using different codecs

   FID semantics are useful when the application only uses one codec at
   a time. When a particular application encodes the same media using
   different codecs FID MUST NOT be used. Some systems that handle DTMF
   tones are a typical example of parallel encoding using different
   codecs.

   Some systems implement the RTP payload defined in RFC 2833, but when
   they send DTMF tones they do not mute the voice channel. Therefore,
   effectively they are sending two copies of the same DTMF tone:
   encoded as voice and encoded as a telephony event. When the receiver
   gets both copies it typically uses the telephony event rather than
   the tone encoded as voice. FID semantics MUST NOT be used in this
   context to group both media streams since such a system is not using
   alternative codecs but rather different parallel encodings for the
   same information.

6. Usage

Camarillo/Holler/Eriksson/Schulzrinne                                9
                    Grouping of the "group" attribute media lines in SIP SDP descriptions are used by several

8.2 Layered encoding

   Layered encoding schemes encode media in different protocols, SIP among
   them. We include layers. Quality
   at the receiver varies depending on the number of layers received.
   SDP provides a section about SIP because means to group together contiguous multicast
   addresses that transport different layers. The "c" line below:

        c=IN IP4 224.2.1.1/127/3

   is equivalent to the following three "c" lines:

        c=IN IP4 224.2.1.1/127
        c=IN IP4 224.2.1.2/127
        c=IN IP4 224.2.1.3/127

   FID MUST NOT be used to group "m" lines that contain the different
   layers of layered encoding scheme. Besides, we do not define new
   group semantics to provide a more flexible way of grouping different
   layers because the already existing SDP mechanism covers the most
   useful scenarios.

8.3 Same IP address and port number

   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used. FID MUST NOT be used to group "m" lines with the
   same IP address/port. Therefore, an SDP like the one below MUST NOT
   be generated.

         v=0
         o=Laura 289083124 289083124 IN IP4 six.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 0
         a=mid:1
         m=audio 30000 RTP/AVP 8
         a=mid:2

   The correct SDP for the session above would be the following one:

         v=0
         o=Laura 289083124 289083124 IN IP4 six.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         m=audio 30000 RTP/AVP 0 8

9. Usage of the "group" attribute in SIP

   SDP descriptions are used by several different protocols, SIP among
   them. We include a section about SIP because the "group" attribute
   will most likely be used mainly by SIP systems.

Camarillo/Holler/Eriksson/Schulzrinne                               10
                    Grouping of media lines in SDP

   SIP [6] 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 [2] is one of
   the protocols that can be used for this purpose.

Camarillo/Holler/Eriksson                                            8
                    Grouping

   At session establishment SIP provides a three-way handshake (INVITE-
   200 OK-ACK) between end systems. However, just two of media lines these three
   messages carry SDP. SDPs MAY be present in INVITE and 200 OK or in
   200 OK and ACK. The following sections assume that INVITE and 200 OK
   are the ones carrying SDP

6.1 Media alignment

   Appendix B of [6] describes for the usage shake of SDP in relation clarity, but everything
   is also applicable to SIP. It
   states: "The caller the other possible scenario (200 OK and callee align ACK).

9.1 Mid value in responses

   The "mid" attribute is an identifier for a particular media stream.
   Therefore, the "mid" value in the response MUST be the same as the
   "mid" value in the request. Besides, subsequent requests such as re-
   INVITEs SHOULD use the same "mid" value for the already existing
   media streams.

   Appendix B of [6] 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 "group" attribute in an SDP session description
   does not modify this behavior.

   Since the "mid" attribute provides a means to label "m" lines it
   would be possible to perform media alignment using "mid" labels
   rather than matching nth "m" lines. However this would not bring any
   gain and would add complexity to implementations. Therefore SIP
   systems MUST perform media alignment matching nth lines regardless
   of the presence of the "group" or "mid" attributes.

6.2 Mid value in responses

   The

   If a media stream that contained a particular "mid" attribute is an identifier for in
   the request contains a particular different identifier in the response the
   application ignores all the "mid" and "group" lines that might
   appear in the session description. The following example illustrates
   this scenario:

9.1.1 Example

   Two SIP entities exchange SDPs during session establishment. The
   INVITE contained the SDP below:

         v=0
         o=Laura 289083124 289083124 IN IP4 seven.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=groupe:FID 1 2

Camarillo/Holler/Eriksson/Schulzrinne                               11
                    Grouping of media stream. lines in SDP

         m=audio 30000 RTP/AVP 0 8
         a=mid:1
         m=audio 30002 RTP/AVP 0 8
         a=mid:2

   The 200 OK response contains the following SDP:

         v=0
         o=Bob 289083122 289083122 IN IP4 eigth.example.com
         t=0 0
         c=IN IP4 131.160.1.113
         a=groupe:FID 1 2
         m=audio 25000 RTP/AVP 0 8
         a=mid:2
         m=audio 25002 RTP/AVP 0 8
         a=mid:1

   Since alignment of "m" lines is performed based on matching of nth
   lines, the first stream had "mid:1" in the INVITE and "mid:2" in the
   200 OK. Therefore, the application MUST ignore every "mid" and
   "group" lines contained in the SDP.

   A well-behaved SIP user agent would have returned the SDP below in
   the 200 OK:

         v=0
         o=Bob 289083122 289083122 IN IP4 nine.example.com
         t=0 0
         c=IN IP4 131.160.1.113
         a=groupe:FID 1 2
         m=audio 25002 RTP/AVP 0 8
         a=mid:1
         m=audio 25000 RTP/AVP 0 8
         a=mid:2

9.2 Group value in responses

   A SIP entity that receives a request that contains an "a=group" line
   with semantics that it does not understand MUST return a response
   without the "group" line. Note that, as it was described in the
   previous section, the "mid" lines MUST still be present in the
   response.

   A SIP entity that receives a request that contains an "a=group" line
   which semantics that are understood MUST return a response that
   contains an "a=group" line with the same semantics. The
   identification-tags contained in this "a=group" lines MUST be the
   same as that were received in the
   "mid" request or a subset of them (zero
   identification-tags is a valid subset). When the identification-tags
   in the response are a subset the "group" value to be used in the request. Besides, subsequent requests such as re-
   INVITEs
   session MUST use be the same "mid" value for one present in the already existing response.

Camarillo/Holler/Eriksson/Schulzrinne                               12
                    Grouping of media
   streams.

6.3 Group value lines in responses

   The "group" attribute SDP

   SIP entities refuse media streams by setting the port to zero in the
   corresponding "m" line. "a=group" lines MUST no contain
   identification-tags that correspond to "m" lines with port zero.

   Note that grouping of m lines MUST always be requested by the issuer
   of the request (the client), never by the issuer of the response
   (the server). Since SIP provides a two-way SDP exchange, a server
   that requested grouping in a response will typically be would not know whether the
   "group" attribute was accepted by the same as client or not. A server that
   wants to group media lines SHOULD issue another request after having
   responded to the first one received (a re-INVITE for instance).

        Note that, as we mentioned previously, in the request. However, there are situations when
   both this section we are different. In these situations the "group" value to be used
   in the session is
        assuming that the one SDPs are present in the response.

        Note the "group value INVITE and in the response" really refers to the
        "group" value in 200
        OK. Applying the last SDP exchanged between both parties.
        That is, if in statement above to the establishment of a particular session
        (INVITE-200 OK-ACK) scenario where SDPs are
        present in the 200 OK and in the
        ACK (not in the INVITE), the "group" value to be used during ACK, the session will entity requesting
        grouping would be the one in the ACK. server.

9.2.1 Example

   The example below shows how the callee refuses a media stream
   offered by the caller setting its port number to zero. The "mid"
   value corresponding to that media stream is removed from the "group"
   value in the response.

   SDP in the INVITE from caller to callee:

         v=0
         o=Laura 289083124 289083124 IN IP4 seventh.example.com ten.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2 3
         m=audio 30000 RTP/AVP 0
         a=mid:1

Camarillo/Holler/Eriksson                                            9
                    Grouping of media lines in SDP
         m=audio 30002 RTP/AVP 8
         a=mid:2
         m=audio 30004 RTP/AVP 3
         a=mid:3

   SDP in the INVITE from callee to caller:

         v=0
         o=Bob 289083125 289083125 IN IP4 fifth.example.com eleven.example.com
         t=0 0
         c=IN IP4 131.160.1.113
         a=group:FID 1 3
         m=audio 20000 RTP/AVP 0
         a=mid:1
         m=audio 0 RTP/AVP 8
         a=mid:2
         m=audio 20002 RTP/AVP 3
         a=mid:3

   Note that although the media stream was refused the "mid" value was
   still included.

6.4 Backward compatibility

   An application that wants to be compliant to this specification MUST
   support both "group" and "mid". Supporting just one

Camarillo/Holler/Eriksson/Schulzrinne                               13
                    Grouping of them would be
   useless. media lines in SDP

9.3 Capability negotiation

   A SIP entity that receives a request client that contains understands "group" and "mid"
   attributes, understands them and it is willing but does not want to
   make use the grouping
   semantics offered returns of them in a response particular session MAY want indicate that also contains "group" and
   "mid" attributes. This way, the it
   supports them. If a client that issued the request knows
   that the server understood this extension.

   Note that grouping of m lines is always requested by the issuer of
   the request (the client), never by the issuer of the response (the
   server). Since there is no response decides to a response in SIP, do that, it SHOULD add an
   "a=group" line with zero identification-tags for every semantics it
   understands.

   If a server receives a request that requested grouping contains empty "a=group" lines
   it SHOULD add its capabilities also in a response would not know whether the
   "group" attribute was accepted by the client or not. form of empty "a=group"
   lines to its response.

9.3.1 Example

   A server system that
   wants supports both LS and FID semantics but does not want
   to group any media lines should issue another stream for this particular session generates the
   following SDP:

         v=0
         o=Bob 289083125 289083125 IN IP4 twelve.example.com
         t=0 0
         c=IN IP4 131.160.1.113
         a=group:LS
         a=group:FID
         m=audio 20000 RTP/AVP 0 8

    The server that receives that request after having
   responded to supports FID but not LS. It
   responds with the first one (a re-INVITE for instance). SDP below:

         v=0
         o=Laura 289083124 289083124 IN IP4 thirteen.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID
         m=audio 30000 RTP/AVP 0

9.4 Backward compatibility

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

   A client that does not want to perform grouping of media lines in a
   session SHOULD NOT add "mid" lines either. The presence of "mid"
   lines would not MUST be of any use for the server. Even if the server can
   see used
   (attributes that the client supported "mid" (and obviously "group" also) it
   would be impossible to know which particular semantics are supported
   (LS or/and FID).

Camarillo/Holler/Eriksson                                           10
                    Grouping of media lines in SDP

6.4.1 not understood are simply ignored).

9.4.1 Client does not support "group"

   This situation does not represent a problem because grouping
   requests is always performed by clients, not by servers. If the

Camarillo/Holler/Eriksson/Schulzrinne                               14
                    Grouping of media lines in SDP

   client does not support "group" this attribute will just not be
   used.

6.4.2

9.4.2 Server does not support "group"

   The server will ignore the "group" attribute, since it does not
   understand it (it will also ignore the "mid" attribute). For LS
   semantics, the server might decide to perform or to not perform
   synchronization between media streams.

   For FID semantics, the server will consider that the session
   comprises several media streams.

   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 server does not support the
   type of session that the caller wanted to establish. In case the
   client is willing to establish a simpler session anyway, he should SHOULD
   re-try the request without "group" attribute and only one "m" line
   per flow.

7.

10. IANA considerations

   As previously stated in section 4, this document defines two
   standard semantics related to the "group"  attribute: LS (Lip
   Synchronization) and FID (Flow Identification). If in the future it
   was needed to standardize further semantics they would need to be
   defined in a standards track document.

11. Acknowledgments

   The authors would like to thank Jonathan Rosenberg, Adam Roach and Roach, Orit
   Levin and Joerg Ott for their feedback on this document.

8.

12. References

   [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
   Levels", RFC 2119, IETF; March 1997.

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

   [3] D. Kutscher/J. Ott/C. Bormann, "Session Description and
   Capability Negotiation", draft-ietf-mmusic-sdpng-00.txt, IETF; April
   2001. Work in progress.

Camarillo/Holler/Eriksson/Schulzrinne                               15
                    Grouping of media lines in SDP

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

Camarillo/Holler/Eriksson                                           11
                    Grouping of media lines in SDP

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

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

   [7] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access
   Networks", draft-westberg-realtime-cellular-04.txt, IETF; June 2001.
   Work in progress.

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

   [9] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits,
   Telephony Tones and Telephony Signals", RFC 2833, IETF; May 2000.

9.

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

   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                                           12

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue

Camarillo/Holler/Eriksson/Schulzrinne                               16
                    Grouping of media lines in SDP

   New York, NY 10027
   USA
   Email: schulzrinne@cs.columbia.edu

Camarillo/Holler/Eriksson/Schulzrinne                               17