Re: [MMUSIC] When a bundle offer is forked

Dale/Christer,

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.

Thanks
Partha

> -----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