Re: [MMUSIC] When a bundle offer is forked

Hi,

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

Ok.

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

I don't see how the UAC is more restricted than in other cases where it would send an UPDATE to UAS1, and then receive an answer on UAS2.

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

Not any IETF document that I am aware of.

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