IETF Logo Mail Archive

Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 17 March 2016 15:34 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 7CFF112D5BA for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 08:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w9x4wlOqbv8 for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 08:34:37 -0700 (PDT)
Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29E212D99B for <mmusic@ietf.org>; Thu, 17 Mar 2016 08:34:35 -0700 (PDT)
Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with comcast id X3aU1s0012GyhjZ013aZNl; Thu, 17 Mar 2016 15:34:33 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id X3aZ1s00F3KdFy1013aZGc; Thu, 17 Mar 2016 15:34:33 +0000
To: mmusic@ietf.org
References: <CALiegfm7Rb4e5DFGycr=EsdigE1XFCUiqNL6+GpRSyrGe=_RWg@mail.gmail.com> <56DED735.1000101@ericsson.com> <CALiegf=G77JOcoR6DORnPsMx4OCgy=_dYQ_r8KfjMy_33vn89A@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E9EA74@ESESSMB209.ericsson.se> <CALiegf=F4z9r+oCO1DMW_nXq7TBJjf-n3N1r6yr5tLoksXtUqg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E9FDAB@ESESSMB209.ericsson.se> <CALiegf=kzThQ3n+Z-=E8G=ivyL1W=Q4gUcQenihAJ3pmv8udKQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37EA257B@ESESSMB209.ericsson.se> <CALiegfnLMUZnA=AQEnvFhxKKbwUeg=sFHRiC9R2MxisY-43UFg@mail.gmail.com> <D31037D8.5B90%christer.holmberg@ericsson.com> <CALiegfmWPrai9a1hkj5rpLeyowspAcpr3jNZpNyc4HatXGfo9Q@mail.gmail.com> <D3103E3F.5BBE%christer.holmberg@ericsson.com> <CALiegfmzO_1nuQmE3SYJk-OtYZ2GHzjfTzkgJ=1zwoRcD+NmCw@mail.gmail.com> <CF1984E6-C1C8-41C5-8B7F-02988342E930@csperkins.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56EACE88.9060208@alum.mit.edu>
Date: Thu, 17 Mar 2016 11:34:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CF1984E6-C1C8-41C5-8B7F-02988342E930@csperkins.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458228873; bh=uKVTO1/cI6GdeKTonQGuAv7rVDv8rBIrVnFe4HIiFis=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LPUsog4/XvLiCUk7HRUDDFgQvRoq9BGpCCtf4GCqecWU9e0RrkZCPkcDeN1khijNC 6Opd+YICLcOORH+nhuYvcoIdG8yI730z/pOXx7KmEuNtJMv1hv8M2C1PsHJMVbbR/f h/YasBPkpzr+M23plJ70Do5nDcqp+3lPFyXC9e7ZfL3IRrypl/NG/9MTwq5dw8S+gV 8rCYuze2kfOIJcyxAnmmkhUy9Wkb8JbtpzDN5911oTlqNsqy6K3AG6AQ5+d2Xf3SWi 51soagpk4YxXkdhSIm5tInOhjovVorNm81Nb7SelLU1FCOT0kowRWY1hWk8keodc2/ W6C6e8Fw6N5aQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/xIh2GrF6sTQTfHny_N0xpnUX6aw>
Subject: Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Mar 2016 15:34:39 -0000

On 3/17/16 6:30 AM, Colin Perkins wrote:
>
>> On 17 Mar 2016, at 09:30, Iñaki Baz Castillo <ibc@aliax.net> wrote:

>> - "RTP session" == stuff carried over a single transport (let's assume
>> rtcp-mux always).
>
> No, RTP session == shared SSRC space [RFC 3550, Section 3, Page 10]. RTCP mux is irrelevant for whether there is a single RTP session or not, and an RTP session can span multiple transports.

I'm not an "RTP person", so it has taken me a long time to "get" this.

What I have learned is that there is a mismatch between SDP, O/A, and 
RTP. In spite of what you might easily infer from 4566 and 3264, O/A 
does *not* negotiate the establishment of RTP Sessions (as defined in 
3550) between the offerer and the answerer. That *might* be the result. 
Or it may be that the result is one end being joined into a preexisting 
RTP session involving other participants.

Because of that, the work on better defining the rules for PT use in 
offers and answers turned out to be a lot harder than I expected. It 
can't just focus on making 3264 unambiguous in its own right. It has to 
deal with the actual rules of 3550. And IIUC, when this is done it 
appears that the result may conflict with current practice in some 
implementations. I don't see any painless way out of this.

	Thanks,
	Paul

v2.23.0 | Report a Bug | By Email