Re: [MMUSIC] Associating packets with m-lines in a bundle

Christer Holmberg <> Mon, 27 May 2013 10:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BCC821F90FD for <>; Mon, 27 May 2013 03:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.503
X-Spam-Status: No, score=-5.503 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s8GX80lyBaCj for <>; Mon, 27 May 2013 03:01:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E1E3F21F8A14 for <>; Mon, 27 May 2013 03:01:04 -0700 (PDT)
X-AuditID: c1b4fb30-b7f8a6d000001a2d-78-51a32edf0f63
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9C.5F.06701.FDE23A15; Mon, 27 May 2013 12:01:04 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 27 May 2013 12:01:03 +0200
From: Christer Holmberg <>
To: Bernard Aboba <>, Paul Kyzivat <>
Thread-Topic: [MMUSIC] Associating packets with m-lines in a bundle
Thread-Index: AQHOV+Zp6PDmzKY1kEezzTQcDF/35ZkUmi8AgAQ21sA=
Date: Mon, 27 May 2013 10:01:02 +0000
Message-ID: <>
References: <> <BLU403-EAS11291D50BCA39955DE3C9C393940@phx.gbl>
In-Reply-To: <BLU403-EAS11291D50BCA39955DE3C9C393940@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre4DvcWBBuv/M1nsX3KZ2WLq8scs Fis2HGB1YPb4+/4Dk8fjnjNsHkuW/GQKYI7isklJzcksSy3St0vgylhwaidTwV/hio2futkb GJ/zdzFyckgImEis3XSXFcIWk7hwbz1bFyMXh5DAYUaJfy/PMUM4SxglXizrZOli5OBgE7CQ 6P6nDdIgIhAqcXTXBLBmZgEViVenL4PZwgJOEhP617FA1DhLXJz4mhXCtpLYtfIp2BgWAVWJ fRtsQcK8Ar4Sly4sYQQJCwnESSw5pQkS5hSwlTjYsIYRxGYEOu37qTVMEJvEJW49mc8EcbKA xJI955khbFGJl4//sYKMkRBQlFjeLwdRriOxYPcnNghbW2LZwtfMEFsFJU7OfMIygVFsFpKp s5C0zELSMgtJywJGllWM7LmJmTnp5eabGIERc3DLb4MdjJvuix1ilOZgURLn1eddHCgkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0SFusdMro9frr0W/PpIulJ13vePMM4/1wZfn1u/MeJ04 J2nbjActV81OdDjkylSf4wzqcZ85dWLEb4YZOkG83yca7J323XX5KoFfXCXHwjL/M3/1c+A3 +ZJ1JdnLN/H5LZ+/C1oFNoW8CuKdm9snz5TgKl7vXhV9e/Wbwp9LU90i56T0nzVpVGIpzkg0 1GIuKk4EAN65ENJmAgAA
Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 May 2013 10:01:13 -0000


I am skeptical towards specifying a default m- line as well, as the media type may not even match :)



-----Original Message-----
From: [] On Behalf Of Bernard Aboba
Sent: 24. toukokuuta 2013 22:35
To: Paul Kyzivat
Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle

On May 23, 2013, at 11:50, "Paul Kyzivat" <> wrote:

> After all the discussion in the meeting today, I thought it would be good to unwind all the indenting and start a new thread on one issue that is part of the "demux" problem:
> IMO the following should obviously be a truism. I want to know if all agree.
> If an O/A exchange negotiates a bundle with multiple m-lines, then 
> attributes in those m-lines and the associated media sections must provide sufficient information to associate each incoming packet on the 5-tuple to exactly *one* of those m-lines.

[BA] I would argue that this statement needs to be true for *both* RTP and RTCP packets.

> (If it doesn't, then there was no point in including those m-lines in 
> the bundle.)
> For instance a=ssrc, if unique to one m-line, can bind packets with that SSRC to the m-line.

[BA] That is only necessary for RTP (and RTCP) if the PT is not unique to an m line; otherwise PT demux is sufficient for RTP.  For RTCP the situation is more complicated. If we only need to bind RTCP packets from RTP senders, we can build an SSRC to PT to m line table dynamically, based on SSRCs and PTs seen in RTP packets.  However if we get a RR from a source that has not yet sent, we can't map it to an m line without a=ssrc if BUNDLE is in use.  

> If a property such as SSRC is used this way, then there is the possibility of receiving packets that don't match any of the m-lines. I think we ought to address that, by defining some syntax to specify what to do with packets that don't match any m-line. This might be to specify one m-line as the default, or that packets that don't match be discarded.

[BA] I do not believe that a default m line makes sense for RTCP packets that can't be bound to an m line.  Discard, while undesirable, seems like the only option. However this could create problems in diagnostics in some cases.

mmusic mailing list