Re: [MMUSIC] 10 BUNDLE questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 24 April 2013 14: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 4E14321F8D31 for <mmusic@ietfa.amsl.com>; Wed, 24 Apr 2013 07:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.294
X-Spam-Level:
X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.143, 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 MsFPCs+p4a6H for <mmusic@ietfa.amsl.com>; Wed, 24 Apr 2013 07:35:39 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5921F866E for <mmusic@ietf.org>; Wed, 24 Apr 2013 07:35:39 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id TnfR1l0060ldTLk5DqbedP; Wed, 24 Apr 2013 14:35:38 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Tqbd1l01P3ZTu2S3Qqbe0Z; Wed, 24 Apr 2013 14:35:38 +0000
Message-ID: <5177EDB9.9030103@alum.mit.edu>
Date: Wed, 24 Apr 2013 10:35:37 -0400
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> <CABcZeBPZ9R-3xO0QOLVPF2O6trNTXSUzeVYLiWY-aYKpXH-wxw@mail.gmail.com>
In-Reply-To: <CABcZeBPZ9R-3xO0QOLVPF2O6trNTXSUzeVYLiWY-aYKpXH-wxw@mail.gmail.com>
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=1366814138; bh=YLUUTkiO1zE8+cgn6kRVQe4U9spN1ZhstU1wu7ni/EM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EbRzgJ5geDBlOsIbKCaIHOQiL0T94heJbly9YPklfMWKkLo0gdx/oFuTSd5sOfNRQ OwFA5HOxAk1zwpOHA75v2ryoa3l2PcEPb26yLjyVpccMD2kKuutk/wkJVzhj7Etf0e nDnRkHeohadWAUDFpZzFVa3BmsjPa/MqN7Dd7ACXKzMgZbjL/9GSmiUJ0QaICAyvzi hta0dCSWd7ec2Il47PcsO9LSv0hXxsBVbzNOeDGdb8uctkL6RWEsSrVFBfwCGIjJ2f pXsO5Nr+nUCtxOMINNZ23NgN7AqMGmH+rMXPoNYwXnzAQZiiTR4wJxzMIhh3kgkj3J C6pP0ZrgP0pNQ==
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: Wed, 24 Apr 2013 14:35:40 -0000

inline, trimming

On 4/23/13 10:16 PM, Eric Rescorla wrote:
> After reading the thread, here are my proposed answers...

>  > When creating an initial offer, how should we deal with the case
>  > where a "null" port is to be used with trickle ICE (since 6.1:1
>  > indicates the ports MUST be different)
>
> I think it's ok for the null port to not be equal.

What is a "null" port?

In any case, ISTM this reply isn't responsive to the question.
IIUC, the question was:

- the current spec says that the initial bundle offer must have
   *different* addr/port for each m-line;

- but if, in conjunction with trickle ice, you want to make the
   initial offer have *null* port, then multiple m-lines will have
   the *same* null port.

This seems to require that the bundle spec acknowledge and permit this case.

>  > If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the
>  > offer, what happens? (assume fail)
>
> That sounds right to me.

Exactly what does "fail" mean here?
It is the receiver of the answer that detects this issue.
Presumably the answerer didn't consider it an error, and
so won't know the offerer thinks it is.

So does "fail" mean that the offerer should tear down the 
PeerConnection? Or what?

>  > If you add a m= line to an existing BUNDLE, can the recipient reject
>  > that BUNDLEing (assume no)
>
> I think life would be simpler if this just caused a negotiation
> fail if the other side was sad about it.

If the change was to add a new m-line, that previously was not present, 
to the SDP *and* to the bundle, then answerer could potentially either:

1) accept the m-line (non-zero port) and accept the bundling
    (matching mid-line to what was in the offer)

2) accept the m-line and reject the bundling (mid value
    for the rejected m-line omitted from the bundle group)

3) reject the m-line (zero port) and reject the bundling. For better
    or worse, RFC5888 requires this behavior in the group line for
    rejected m-lines.

I guess you are suggesting that (2) be unacceptable. Again, what do you 
expect to happen in that case?

>  > If m= lines are rejected, should their mids show up in the BUNDLE
>  > answer? (assume yes?)
>
> That sounds easiest.

I think RFC5888 requires this. (But it may be arguable.)

But it also requires that the group in the answer not reference the mid 
tag of the rejected m-line.

>  > Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>  > that were previously BUNDLEd (assume no)
>
> I would say no.
>
> After all, you can always discard those lines and offer new lines.

ISTM there are more details to be worked out:

* When is an m-line considered to have been "previously bundled"?

   - Is it when it was first offered with a mid tag referenced by
     a bundle group line?

   - Or is it the first time the mid tag appears in a bundle group
     in an answer?

   ISTM it should be the latter, not the former. That means m-lines
   that were offered but rejected in the answer are not bundled,
   and so can be reused in a subsequent offer to propose a separate
   bundle.

* When "offering new lines", must those lines really be *new*,
   or can they include the recycling of m-lines that were previously
   rejected?

   Precedent says that these are functionally equivalent.

* Is there any requirement for preservation of mid tags from
   one O/A cycle to the next? IOW, is the *value* of the mid tag
   for each m-line part of the persistent state of the session?

   - I think there is a requirement that the *bundling* be
     preserved;

   - But the mid tags are merely a means to an end for describing
     the grouping. It is not important that the specific tags
     be preserved.

   - There could be a difference between what is required here
     for 3264 usage and what is required for JSEP, since the
     usage for JSEP is not a wire protocol.

Thanks,
Paul