Re: [MMUSIC] When a bundle offer is forked

Christer,

My intention of the below mail is to say that the offer/answer interaction
issues created by BUNDLE for forking and it has to be documented. Also, it
is not implementation issue but more of protocol design issue. Please read
inline for more comments.

Thanks
Partha

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Monday, May 27, 2013 1:44 PM
> To: Parthasarathi R; 'Dale R. Worley'; 'Paul Kyzivat'
> Cc: mmusic@ietf.org
> Subject: 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.
> 
<Partha> UAC choice is restricted to the above choice because of BUNDLE.
This has to be mentioned in the document </Partha>

> Also, BUNDLE is not the only SIP/SDP mechanism which uses multiple
> Offer/Answer transactions.
> 
<Partha> I agree with you that multiple offer/answer transaction is not just
by BUNDLE. Please indicate whether any document mention the issues related
forking with  multiple offer/answer. </Partha>

> 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