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

Paul Kyzivat <> Mon, 27 May 2013 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADBC021F96C5 for <>; Mon, 27 May 2013 08:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 zs3VxWcXgQU5 for <>; Mon, 27 May 2013 08:55:16 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:40]) by (Postfix) with ESMTP id 4594A21F8ED8 for <>; Mon, 27 May 2013 08:55:15 -0700 (PDT)
Received: from ([]) by with comcast id h3mq1l00217dt5G543vF9V; Mon, 27 May 2013 15:55:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id h3vF1l00F3ZTu2S3Z3vF9F; Mon, 27 May 2013 15:55:15 +0000
Message-ID: <>
Date: Mon, 27 May 2013 11:55:14 -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: Bernard Aboba <>
References: <> <BLU403-EAS11291D50BCA39955DE3C9C393940@phx.gbl>
In-Reply-To: <BLU403-EAS11291D50BCA39955DE3C9C393940@phx.gbl>
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=1369670115; bh=Z8xaOhN7CRKzNfeDOTEvDGRIb+aZHhxFj8GkqLqm2DQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aQ6RQaoxiTswQHg6+ZgeyPOLZ9Dl9aeycfy5V1t3I4Mo5DrcL2w+XJDU9WnqZmO5a pQBeKnb+qnKokaTlMrTtBHQu3kErhhosCTt6A2tE+vs5aTPlKrLwzX0g7AfNd0mquW n03jSkceVJqLB6NEe1WA7+ZWn0tY8JDsvZO+q0zwibfJTfH97Phe5JdiF3Gq7XZ8CZ /5cbKoVb/xcxzGFVzu+NmGSv38kgtxru8FdH9LDb1RQBybtHoAjYkM9WBpKSt4mM2B pWqkWx7KdTLP2tBmH3WyUZl2mOk4Qs8YovEAqPF0Jda3pvElZgf6CWcR5e+iYHt+ag i5lzWmeWjykHg==
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 15:55:23 -0000

On 5/24/13 3:34 PM, Bernard Aboba wrote:
> 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.

I don't know enough to comment on that, but it sounds right.

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

I discussed that elsewhere. There are several features that, when 
present in the SDP and in the packet, can be used to bind the packet to 
the m-line. The PT has the advantage that it is always present in RTP 
m-lines, and is always present in RTP packets. But as you mention, I 
guess it is not present in RTCP packets.

I'll also note that PT doesn't help when bundling non-rtp m-lines, such 

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

Again, I'll defer to others that know more about this.