Re: [MMUSIC] 10 BUNDLE questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 05 April 2013 00:35 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 7D9E021F8E7A for <mmusic@ietfa.amsl.com>; Thu, 4 Apr 2013 17:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.362
X-Spam-Level:
X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 RjOFa+N+RD8w for <mmusic@ietfa.amsl.com>; Thu, 4 Apr 2013 17:35:08 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id C3F0A21F8E6C for <mmusic@ietf.org>; Thu, 4 Apr 2013 17:35:07 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id KnY71l0060vyq2s550b72F; Fri, 05 Apr 2013 00:35:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id L0b61l01L3ZTu2S3R0b7qP; Fri, 05 Apr 2013 00:35:07 +0000
Message-ID: <515E1C3A.3050309@alum.mit.edu>
Date: Fri, 05 Apr 2013 08:35:06 +0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CAOJ7v-0tr6_HAPwOnLD_De-LkNCsj1EfLhZL=G_B=k5tz9Hkwg@mail.gmail.com> <03FBA798AC24E3498B74F47FD082A92F36EBBB41@US70TWXCHMBA12.zam.alcatel-lucent.com> <CAOJ7v-0ZKA=-UXA-evYkkyfhDWPyHj4MJfs1V+=MZMCB3Kw4yg@mail.gmail.com> <03FBA798AC24E3498B74F47FD082A92F36ECB275@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F36ECB275@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365122107; bh=GWinshaMgPtv/QdDbKO7d8/tLnoYfCey7NlO6iQ3zJc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cciI7wKh7pS3B7rYfzu98Js/ut1rBO1VQBRK7ycrVCw1ZF4ofJF4y/j5nnAMR2mRz /HEz81VBFRJQJS75ApASDU9mz7rY+3dQQxCwCIKNElOoc7boNFl0KwD8cFtgK/bCJx 3d1T241neemlgP+b7q/oDqCkqCpfSe5lCbcuDj/ickFa0NqzwMHNXtQSinarQICFdw a/IUisZYCG0D6e6bYKQLPsF+aXo5cU5bN4m4xgVKN6BnumN4zbLlbLPVon+LjkRqf+ 1XwfJ0YtsgDs5ZDuVkL4NwoE4Ggg1tQhtRt9CpifZZO2yaDa0PAZkWVD98x7oJOivE KOSZ01cZM6ENA==
Subject: Re: [MMUSIC] 10 BUNDLE questions
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: Fri, 05 Apr 2013 00:35:08 -0000

Replying to Justin,

(For some reason I got Richard's replies to Justin, but not the messages 
from Justin!)

On 4/5/13 4:36 AM, Ejzak, Richard P (Richard) wrote:

>>> 10: I think we have to have the ability to unbundle within a PeerConnection.  For the error case described (twice) at the mike in Orlando, if the first answer comes back asking to bundle but signaling different ports, it is because of an intermediary forwarding bundle attributes without understanding them while remapping ports.  There seemed to be agreement in this case (or at least the opinion was expressed) that the offerer needs to detect this condition and send a 2nd offer with different ports and without bundle (else the answerer will continue to assume bundle while the intermediary will not).  Note that this case appears (to the answerer) as if bundle is successfully negotiated but then it is immediately removed with the 2nd offer.
>>>   u
>>> I think we also have the 3pcc use case where a mid-call bundled offer goes to a different endpoint that chooses not to bundle.  As long as it removes the bundle attributes and returns different ports, why should we disallow this?  It only requires an ICE restart.  This will even work with most (new) intermediaries except those that choke on seeing the same port in multiple m lines.  Which brings me to why I think we also need to be able to indicate via the API whether a mid-call offer is to be signaled with the same or different ports for a bundle group (as I also requested at the mike).
>
>> I think this is harder than you say. It's more than an ICE restart, it also requires re-keying of SRTP (since we now need unique crypto per m-line) and dealing with the sort-of-BUNDLEd case where we need to be able to receive BUNDLEd and non-BUNDLEd media potentially simultaneously during the transition. I'd really like to avoid having to deal with this.

There are lots of things that I would really like to avoid dealing with.
(E.g. income taxes.)

But just because I would like to doesn't mean I can.
3pcc scenarios break a lot of first proposals for how to do things.
The solution is to fix the proposal so it still works.
You can't control whether this happens to you.

	Thanks,
	Paul