Re: [MMUSIC] When a bundle offer is forked

I don't think dealing with forking with bundle is any different that dealing with forking without bundle. The key thing is we are not using bundle with multicast. 

On May 23, 2013, at 11:34 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 5/23/13 6:35 AM, Emil Ivov wrote:
> 
>> In case a bundle offer gets forked and various answers ...
> 
> I trimmed everything else out of Emil's reply, and changed to subject, because this is a whole different can of worms!
> 
> I think we must acknowledge that this *can* happen, though it is a low probability event. It raises all sorts of ugly issues. A few:
> 
> * if the bundle is accepted by multiple forks, does this form
> one RTP session or several? If so,

same as if your were not doing bundle in O/A without multicast - they are different 

> 
> - if so, then if each fork accepts a different set of m-lines from
>   the bundle, how can that work with a single RTP session?

so they are not a single session but again, it's pretty much the same as if you were not using bundle and things the forks accepted different sets of m lines. 

> 
> * How does ICE work in this case? (Is that already covered by ICE,
> since it mostly isn't specific to bundle?

exactly the same as if you were not doing bundle but there are less ports to set up 

> 
> * If one fork adds/removes an m-line from the bundle, should that
> be mirrored to the other forks?

huh - no. I can't even imagine what this means. Think about this in a non forking case. A sends an offer with audio and video that forks to B and C. B replies accepting only the audio, C replies accepting both. A is likely to end up ending one of the forks all together but it's not like A tires to until the media from B and C. 

> 
> * ...
> 
> ISTM that the simplest thing we could do about this is put a statement in the draft that this draft does not specify behavior in the case of forking - that conforming devices are constrained to a single fork, and that behavior in forking cases could be a subject of future standardization.

Sorry but that won't work. I don't see any actual problem identified where bundle complicates the existing forking issues. 

When the devices creating the offer and offer bundle, it has no idea if that offer will end up being forked or not. 

> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic