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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 05 June 2013 16:17 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 8FDCB21F9B2A for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.03
X-Spam-Level:
X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
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 0F-1d9p7AMs6 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:17:22 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8439721F9987 for <mmusic@ietf.org>; Wed, 5 Jun 2013 09:17:22 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id kbUL1l0020mv7h059gHMM1; Wed, 05 Jun 2013 16:17:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id kgHM1l00n3ZTu2S3XgHMwJ; Wed, 05 Jun 2013 16:17:21 +0000
Message-ID: <51AF6490.1040409@alum.mit.edu>
Date: Wed, 05 Jun 2013 12:17:20 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Cullen Jennings <fluffy@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
In-Reply-To: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370449041; bh=s10lsHXjV55Lssfc87WLenn0KE/LpOAc7Bu6Vwux374=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GivhvwD/vE8l8Qb8qRab9lBQlAV2U9gYO/d2iqm5SblKwuT3mjATuqTf+doqxPIOV LGr5Xanh1uLG3wVZhEBdL9W2ZKjaF3THklmn4OXErHoFcnG2mkzI6H96vMv8H9dTAK P6ujyDHo0ohMxg+bLfvFH5DX3zm2LIsZ6hpvJpXt1i1+NU/SsBBhE4L03/HAqt08UD Pkh5CPXVFm8QjqLieyaC+oqnj4Nc6Ld59F76+EcuqkNLR2JL2ofqXP9Ai0RGx0E0+1 IFbSfRkfzqTNYTpJq16YQgmfzUPunOYvdoKaWGgkE2WFkV0mHDRUIGBqFQ6Hg6HM2M wBGMHZd376cUQ==
Cc: 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 16:17:28 -0000

On 6/3/13 6:51 PM, Cullen Jennings wrote:
>
>
> Imagine Alice sends  an offer containing
>
> On May 27, 2013, at 10:56 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>> m=audio 49172 RTP/AVP 96
>>   a=ssrc:2222 cname:alice@example.com
>>   a=rtpmap:96 G7291/16000
>
> Let say that an offer sent like the above. That means nothing about the SSRC for the packets that Alice will receive. And it is likely to receive RTP packets before it receives an answer in some important scenarios.

You keep saying that. But is it really true when ICE is used?
Need it be true even without ICE? After all, bundle is new usage, so we 
can demand new behavior when using it. So requiring a reliable 
provisional with an answer before sending media doesn't seem so 
unreasonable.

> So a RTP packet SSRC 3333 arrives. There's no information from the SSRC about what m-line it matches too (but RTCP for it can be sent).

My point is that if you choose to bundle, then there must be *some* 
mechanism to associate packets with m-lines. If you don't find the use 
of SSRC to be an acceptable solution, then feel free to construct your 
offer so that PTs are sufficient to do that association. But I don't see 
why the mechanism we specify must require that.

> Now an answer from Bob arrives with
>
> m=audio 55555 RTP/AVP 96
>   a=ssrc:4444 cname:bob@example.com
>   a=rtpmap:96 G7291/16000
>
> Now a packet with SSRC 4444 arrives. That might be from Bob, but here's the rub. It might be from Charlie. If there was an SSRC collisions between Bob and Charlie, it will be awhile before some SDP shows up that says that there was a collisions and now Bob is using SSRC 5555.

Here you are assuming that the invite was forked, and that both forked 
endpoints send early media, and they manage to have an SSRC collision on 
the early media? (And both Bob and Charlie had the winning ticket on 
last night's Power Ball???)

We are supposed to worry about that case???

> This is all a disaster and the best solutions to it IMHO would be to define a new RTP Header extension that carries and identifier and that Alice can tell Bob in the SDP offer what value to put in the identifier for the RTP from Bob to Alice.

That is another solution.
But do we want to require that all media providers do this?
Wouldn't it be less onerous to simply require an early answer?

I'm concerned with requiring the sender to insert something in the media 
that is specified by the receiver. That makes it harder to distribute 
the same media to multiple destinations.

I do think we want a header extension that contains something 
independent of SSRC that may be used to associate related packets. (That 
can be used by clue to carry capture-id.) But I don't think it needs to 
be defined by the receiver.

	Thanks,
	Paul

> I've see more than one system that have stuffed that identifier in the existing CSRC field which is sort of an awful hack and sort of very cool.
>
>
>