Re: [MMUSIC] When a bundle offer is forked

Hi,

>Forking has to be seen with the RTP role (endpoint, translator, mixer) as the offer/answer exchange varies drastically for each RTP role. SIP 
>forking with RTP endpoint issues are explained as part of Sec 3.1 of RFC 3960. One of the complexity introduced as part of BUNDLE is to have 
>two offer/answer before consolidating. The offer/answer interaction between SIP forking with RTP endpoint and BUNDLE has to be mentioned. I'll explain with the SIP serial forking with RTP endpoint scenario for more clarity
>
>1) INVITE with SDP having BUNDLE offer and different port in each m-line is send out from UAC
>2) 183 with SDP and BUNDLE support is received from UAS1
>3) UPDATE with SDP having BUNDLE offer and single port in each m-line is send towards UAS1 after completing PRACK & 200
>4) 183 with SDP and BUNDLE support is received from UAS2
>
>Here at Step 4, it is not possible for UAC to "mute" UAS1 as one another OFFER is initiated already at Step 3 and BUNDLE forces to "mute" the answer 
>UAS2. This limitation has to be mentioned as part of BUNDLE. Please let me know your opinion on this.

I don't understand. The UAC can:

1) wait for the UPDATE answer from UAS1, and then send a new "mute" UPDATE; or
2) send a BYE to UAS1, and terminate the whole early dialog.

Also, BUNDLE is not the only SIP/SDP mechanism which uses multiple Offer/Answer transactions.

Regards,

Christer

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On 
> Behalf Of Christer Holmberg
> Sent: Friday, May 24, 2013 1:55 PM
> To: Dale R. Worley; Paul Kyzivat
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] When a bundle offer is forked
> 
> Hi,
> 
> I agree with Dale. Each early dialog is handled separately.
> 
> From a standards perspective, I don't think we need to say much about 
> forking in BUNDLE, other than maybe some general words that it may 
> happen.
> 
> Then, whether it becomes tricky to implement, e.g. if one early leg 
> uses BUNDLE and another doesn't, is another issue. But, as SIP has 
> mechanisms to terminate early dialogs you don't like etc, I see this 
> as a pure implementation issue.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On 
> Behalf Of Dale R. Worley
> Sent: 24. toukokuuta 2013 1:07
> To: Paul Kyzivat
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] When a bundle offer is forked
> 
> > From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> >
> > 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:
> 
> Is this actually complicated?  That is, worse than is already the case 
> in SIP...
> 
> My understanding is that in SIP (and this must be a SIP situation), 
> each fork proceeds with completely independent state from all other 
> forks.  The forks happen to share sending/receiving ports, but the 
> received packets can be demultiplexed to the correct fork based on 
> their sending addresses.  Of course, there are a range of obnoxious 
> situations where you receive packets before you receive a SIP response 
> (SDP answer) that describes them, but that is true in non-bundled SIP 
> as well.
> 
> Dale
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic