Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

Paul Kyzivat <> Wed, 05 June 2013 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA9D421E804C for <>; Wed, 5 Jun 2013 15:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mfJqaG61oLtD for <>; Wed, 5 Jun 2013 15:18:44 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:40]) by (Postfix) with ESMTP id 7423F21E8051 for <>; Wed, 5 Jun 2013 15:18:14 -0700 (PDT)
Received: from ([]) by with comcast id kcTl1l0020EZKEL54mJD6u; Wed, 05 Jun 2013 22:18:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id kmJD1l00L3ZTu2S3MmJDDA; Wed, 05 Jun 2013 22:18:13 +0000
Message-ID: <>
Date: Wed, 05 Jun 2013 18:18:12 -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
References: <> <> <> <> <>, <> <>, <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370470693; bh=98SinwJCzkRMvq/qqxgHhAyjwu99X5/Su+P6w1fYXbU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sHOXNchtn2SWIquxiuE00F7L6GWGd4yuzOt3OHK8WSzq11Pf0XcjTrLbC1iViF/hv ZVM4FkU3Xlq3sV8+LWrxf+lWQg1hSkAGapN1jtDXjzEMH2Rj4YvnKm2ntwosFZZpTX GZ2XB8h/cXHrn1LS/4TxPVKP1zfejuYh/pVY81JbZydh/ij4xccMHSjs+tJUVAmCwf ai803i95SEyLoFIe2ndBakxmgZGimZ2VXZoZw7Sqh7aLrW5MXta9o4Rj3bc3Cyrtxa NHHEMPsQdgAWOBOVv/Pn30Hh8OfowQwmcl7ENe7QTudZcXBxzNmHicO6gaRNW/oO99 ikxCfSMZbc7WA==
Subject: Re: [MMUSIC] Scope of RTP payload types in 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: Wed, 05 Jun 2013 22:18:49 -0000

On 6/5/13 1:01 PM, Christer Holmberg wrote:
> Hi,
>>> I think there are many reasons why one would want to use different m- lines. Eventhough the transport characteristics are the
>>> same (if you use BUNDLE, that is), there other things that may be different. Just to give a simple example: the direction attribute value, content attribute value, and anything related to the "scope"/"context" of the m- line.
>> Christer - I suspect we are on the same page.
>> I agree there are many reasons one might want to bundle m-lines.
>> But I assert that every one of those reasons will also require that you be able to associate incoming packets with a particular one of those m-lines.
>> I don't understand why this is in question. I originally stated it as a truism because I thought it was self evident.
> Me too. My assumption has from the start been that we need *A* mechanism to associate media with m- lines, as there might be m- line specific characteristics (I haven't gone through all SDP attributes etc with that in mind, though, so I can't give concrete examples at this point) that are needed in order to properly process the media. I thought that relying on PT and/or SSRC/CNAME would cover all cases, but obviously it doesn't.
> For example, I PERSONALLY think one can assume to receive an SDP Answer (including SSRC/CNAME information etc) before media is received. But, as Cullen has another opinion I don't want to waste time on arguing about that - and I am fully aware what 3264 says about receiving media before the SDP answer :)

My understanding of this has been evolving as the discussion has 
continued. That is why I was eventually motivated to start the thread
"Associating packets with m-lines in a bundle" because I thought it was 
a way to crystalize that issue without having to initially agree on 
*how*. But it turns out that apparently it still isn't universally 
agreed that its necessary to do that association!

The "Plan" discussions make clear that how you intend to use bundling 
impacts how hard the association will be and what mechanisms for doing 
it might be sufficient. For instance, if you never bundle more than one 
m-line of each top level media type (one audio, one video, ...) then PT 
will probably be sufficient to get the job done. If you use Plan A with 
a separate m-line for each of 64 video thumbnails, then maybe not. If 
you use Plan A with CLUE, dynamic switched captures will need something 

So I'm now thinking that BUNDLE with have to be defined without 
agreement on how the association is done. Rather, it will be up to uses 
of bundle to specify that.


> Regards,
> Christer
>> -----Alkuperäinen viesti-----
>> Lähettäjä: []
>> Puolesta Paul Kyzivat
>> Lähetetty: 5. kesäkuuta 2013 18:53
>> Vastaanottaja: Cullen Jennings
>> Kopio:
>> Aihe: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
>> On 6/3/13 6:49 PM, Cullen Jennings wrote:
>>> On May 27, 2013, at 1:13 PM, Paul Kyzivat <> wrote:
>>>> On 5/27/13 2:52 PM, Colin Perkins wrote:
>>>>>>>> In the example above the same payload format, within the same RTP session, is used in two separate m- lines. But, I still can't use the same PT value for both m- lines, even if the payload format is the same, can I?
>>>>>>> Why not? I don't see any problem mapping the same payload type to the exact same payload format in two different m= lines.
>>>>>> But, when I receive media with that payload format, how do I know to which m- line it "belongs", as the same PT value is used for both m- lines?
>>>>> You don't. If you care about that, you need to either use distinct PT values for each m= line, or signal SSRCs.
>>>> I assert that if you don't care about associating a packet to a particular m-line in a bundle that you don't need to use bundle.
>>> I'm not sure this makes a huge difference to your argument but I don't think I agree with the above.
>>> It seems that even if you don't care which m-line the media get associated with, if you want to use a single port for all the m-line, you still need bundle.
>> I don't understand. Why do you want to use multiple m-lines on one port?
>> If you don't need to associate the packets with a particular one of those m-lines, then why didn't you use a single m-line?
>> E.g., if your reason is because one is audio and another is video then you certainly want to associate the packets with one or the other.
>> ISTM that the whole point of Plan A is that each m-line is associated with a specific use/rendering, and so it is essential to associate incoming packets with a particular one of the m-lines.
>> 	Thanks,
>> 	Paul
>>>> So if you used bundle, you must care, and so there must be a way to achieve that association.
>>>> The reason you care is because doing so allows you to discover all the other things in that media section of the SDP that may be pertinent to this packet.
>>>> 	Thanks,
>>>> 	Paul
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list