Re: [MMUSIC] 10 BUNDLE questions

[Paul Kyzivat <[e-mail]>]

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