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

Cullen Jennings <fluffy@iii.ca> Wed, 05 June 2013 00:01 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8410B21F9A23 for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.18
X-Spam-Level:
X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZaaccf0xnyf for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:01:48 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A95321F9A21 for <mmusic@ietf.org>; Tue, 4 Jun 2013 17:01:48 -0700 (PDT)
Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C297422E253; Tue, 4 Jun 2013 20:01:45 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <63BA9030-983D-4426-A378-C6634F77D4DA@csperkins.org>
Date: Mon, 03 Jun 2013 16:50:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BCCF310-7FC5-4590-987E-32A7AB7A82BD@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <6D94E7F9-1AB2-4B39-8750-434FFFC5293A@cisco.com> <63BA9030-983D-4426-A378-C6634F77D4DA@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.1503)
Cc: "mmusic@ietf.org WG" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 00:01:52 -0000

On May 27, 2013, at 8:05 AM, Colin Perkins <csp@csperkins.org> wrote:

> The SSRC identifies the source in RTP: that's fundamental to the design of the protocol. 
> 
> If Plan A wants to use unique PT values to determine how and where a source is rendered, that's fine, subject to the limited number of PT values. I don't think it's fine to redefine the PT as identifying the source.
> 
> Colin


Again we might have confusions on the word source. In the sense Colin means source in which RTP speaking computer (or application on that computer), I agree with Colin. My defines in above sentence is pretty fluffy but the key thing is source seems pretty well defined in RTP and it's identified by the SSRC information (which might show up in a CSRC field). 

But I think some people use source sometimes to mean if the media originated from the microphone or the camera - that's not how RTP uses the word source but if people mean camera or microphone, then some of that might be learned from the PT.


> 
> 
> 
> On 27 May 2013, at 14:47, Mo Zanaty (mzanaty) wrote:
>> The gist of Christer's question is: unique payload types just for unique payload formats, or also for unique sources? I think we all agree the former is true, and this seems to be Colin's point below. But Plan A proposes the latter and extends PT uniqueness to identify sources not just payloads.
>> 
>> Mo
>> 
>> 
>> On May 27, 2013, at 9:05 AM, "Colin Perkins" <csp@csperkins.org> wrote:
>> 
>> On 27 May 2013, at 14:02, Christer Holmberg wrote:
>>>>>>> There were a number of comments in the call last week, and on the list, about unique payload types in BUNDLE. I'd like to explore this further.
>>>>>>> 
>>>>>>> Case A: Within a single RTP session, I think we'd all agree that an offer that uses the same RTP payload type for two payload formats on a single m= line is problematic: 
>>>>>>> 
>>>>>>> v=0
>>>>>>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com  s=  c=IN 
>>>>>>> IP4 host.anywhere.com
>>>>>>> t=0 0
>>>>>>> m=audio 49170 RTP/AVP 96
>>>>>>> a=rtpmap:96 AMR-WB/16000
>>>>>>> a=rtpmap:96 G7291/16000
>>>>>>> 
>>>>>>> If this were done the receiver would have no way of distinguishing what payload format is meant by payload type 96. Accordingly, unique payload formats need to be used for each payload format.
>>>>>> 
>>>>>> That should be "...unique payload types need to be used for each payload format" of course.
>>>>> 
>>>>> What if you have two m- lines, with identical encoding in both? Both 
>>>>> represent the same payload format, don't they? :)
>>>>> 
>>>>> v=0
>>>>> o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 
>>>>> host.anywhere.com
>>>>> t=0 0
>>>>> m=audio 49170 RTP/AVP 96
>>>>> a=rtpmap:96 AMR-WB/16000
>>>>> m=audio 49170 RTP/AVP ???
>>>>> a=rtpmap:??? AMR-WB/16000
>>>> 
>>>> Not sure I get your point. You can have two different payload types that map to the same payload format in a single RTP session, since
>>>> you can always distinguish what payload format is intended. You can't have the same payload type mapping to two different payload 
>>>> formats in a single RTP session, since you can't then infer what payload format was meant. 
>>> 
>>> Please not that both PTs map to the SAME payload format :)
>> 
>> 
>> I thought I addressed that in my reply.
>> 
>> -- 
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic