Re: [MMUSIC] 10 BUNDLE questions

[Paul Kyzivat <[e-mail]>]

On 4/19/13 12:19 PM, Cullen Jennings (fluffy) wrote:
>
> On Mar 15, 2013, at 2:51 PM, Justin Uberti <[e-mail]> wrote:
>
>> The list below is a set of questions (some marked as OPEN ISSUE already) regarding the new BUNDLE proposal. If you agree with my suggested answers, I'm willing to contribute text accordingly.
>> 	• Can you create a BUNDLE with a single m= line? (assuming yes)
>
> yes, have to to add more later
>
>> 	• Can you create multiple BUNDLEs? (assuming yes)
>
> yes but a given m line can only be in one
>
>> 	• 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 we should change bundle to allow the null port
> - it really needs to be all the parameters related to transport / crypto need to be different, or at least as different as they would be required to be if you were not doing bundle. Key thing is if other side does not understand bundle, this looks like an "normal" offer with no bundle.

When you say "null" port, do you mean *zero* port?

There is a technical problem with this. RFC5888, section 9.2, says:

    SIP entities refuse media streams by setting the port to zero in the
    corresponding "m" line. "a=group" lines MUST NOT contain
    identification-tags that correspond to "m" lines with the port set to
    zero.

This means you can't initially establish a bundle group including 
m-lines with zero ports and then negotiate a non-zero port later. To 
work around this we would either need to use some other port (e.g. 9 - 
discard) to indicate no media is initially to be sent, or else change 
RFC5888. Even then it would be necessary to change allow bundle to allow 
multiple bundled m-lines to have the same port in this case.

>> 	• If m= lines are rejected, should their mids show up in the BUNDLE answer? (assume yes?)
>
> don't care but we need to be clear should happen.

See above. This is currently specified by 5888. IMO what is specified by 
5888 is unfortunate. I'm undecided whether its better to try to work 
around it or change it.

>> 		• If not, how does remote side indicate BUNDLE support if it rejects the m= lines that are BUNDLEd?
>> 	• Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd (assume no)
>
> In SIP terminology, I think we would do this with an "INVITE with replaces". If you want to do this, you just start a whole new offer that is not an evolution of the previous set of offer/answers. So basically I am saying not to do this at the bundle level but instead support it at the signaling level.

IMO it would be better to allow bundling to be changed in a subsequent 
O/A, just as anything else it.

>> _______________________________________________
>
> Also imagine case where
>
> Alice offers A, B, and C and offers to bundle them all
>
> Bob wants to accept A and B in a bundle and C separate
>
> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling).

This is a subcase of "splitting" a bundle, which I posted on earlier:

http://www.ietf.org/mail-archive/web/mmusic/current/msg10683.html

IMO it *must* be permissible to accomplish this in some way.
For the case of splitting one bundle into two bundles, I concluded that 
it will take another O/A. Just leaving some of the proposed bundle 
candidates out of single bundle seems to be acceptable to 5888. I see no 
reason to circumvent that for bundle groups.

	Thanks,
	Paul