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

Paul Kyzivat <> Mon, 27 May 2013 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 899E821F96E0 for <>; Mon, 27 May 2013 09:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7bSg0wn1zA6y for <>; Mon, 27 May 2013 09:07:31 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:40]) by (Postfix) with ESMTP id A684021F96C6 for <>; Mon, 27 May 2013 09:07:30 -0700 (PDT)
Received: from ([]) by with comcast id h0og1l0061GhbT85447Vp4; Mon, 27 May 2013 16:07:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id h47V1l00q3ZTu2S3T47VhD; Mon, 27 May 2013 16:07:29 +0000
Message-ID: <>
Date: Mon, 27 May 2013 12:07:28 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Christer Holmberg <>
References: <> <BLU403-EAS11291D50BCA39955DE3C9C393940@phx.gbl> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1369670849; bh=FYiQLaY8gX4bVG9F3wFMzr/ohxQyjP2ZYPDYKq2V1lk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hgtqg1TZsKxmXrBxCXmTaCcV8fxNTHYK6ONz7GFLrloGlo6viW+Wymn+EEI31b/Zs 90AH3Rd44WtvgsK+lJV7sn7TYij4SGIFHi+ZmJ7SDxWlQAVUXd1sba9CNHGH8KfWtD C4mCoZ3vn5bRTjijg6XjM7A1wem6N5gYUiy14hycSOHlZGQspfPZwueUTnE2/fnBM/ 8v1TvoqAcAqI69wCBDkGRdiXg6ehwpaCqvpRYztPYrFl80aoCFo7oCN6U+tL7dzLWt v/MdnlufwSBBiBgqHr499KwpJ4u+A89pwm+tagXqgvPoffYxVQYmi1ls7JyuU26lde NXW2eiO9F07pw==
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 16:07:35 -0000

On 5/27/13 6:01 AM, Christer Holmberg wrote:
> Hi,
> I am skeptical towards specifying a default m- line as well, as the media type may not even match :)

That problem can occur even without defaults: E.g., I could put an 
a=ssrc with a video m-line, while it turns out that the packets with 
that ssrc are audio packets.

This needs to be part of the matching process. All of the specified 
things must match. That does mean that it should be possible to specify 
a=ssrc:* for both an audio and a video m-line. (And for any other top 
level media types.)


> Regards,
> Christer
> -----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