Re: [MMUSIC] When a bundle offer is forked

"Parthasarathi R" <partha@parthasarathi.co.in> Mon, 27 May 2013 16:28 UTC

Return-Path: <partha@parthasarathi.co.in>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514721F9675 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 09:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.515
X-Spam-Level:
X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kM8TCwtoVYp for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 09:28:15 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id ADDDF21F9007 for <mmusic@ietf.org>; Mon, 27 May 2013 09:28:15 -0700 (PDT)
Received: from userPC (unknown [122.179.80.84]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 44F06648098; Mon, 27 May 2013 16:28:09 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1369672095; bh=c49WvOAQfy4wd7lKJ3DT0H9ic55F+YS9+rqjJT2PUv4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=By/uOoT4bhdFv14dnX2hqXg1p3h4D0BJI2e3Txy6DThcf9uWC0StHExT677nnl3UJ 48Tx2BAoUvZb15IqU2VOqw5EHnx6KkKJmF1yQw5Lqn0Dl1SgH0VphN8bX4uVDKPGYj z2m9TR7e56R4zQCn5Z0XI0zbU4MuDU6a8sm3I8p0=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: "'Christer Holmberg'" <christer.holmberg@ericsson.com>, "'Dale R. Worley'" <worley@ariadne.com>, "'Paul Kyzivat'" <pkyzivat@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C374357@ESESSMB209.ericsson.se> <519A1336.9010001@jitsi.org> <9F33F40F6F2CD847824537F3C4E37DDF1159D127@MCHP04MSX.global-ad.net> <519A229D.7090204@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C374463@ESESSMB209.ericsson.se> <519A2768.5010904@alum.mit.edu> <CAPvvaa+A=LkYp9A+wENAABwCYaQcD0HVeX4o+O_16iJRPXZfNw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3744DC@ESESSMB209.ericsson.se> <CAPvvaaJsPNk1DAJXYoc8aUgZ0ZayV_8q84W=Mm7vwuRRGuwC-g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C374572@ESESSMB209.ericsson.se> <519A3883.8060006@jitsi.org> <519A3C8F.3040309@alum.mit.edu> <519B343A.30704@jitsi.org> <519BB598.1030909@alum.mit.edu> <519DF0F8.1070407@jitsi.org> <519E530C.60705@alum.mit.edu> <201305232206.r4NM6l5C5338062@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C377609@ESESSMB209.ericsson.se> <004d01ce5a08$a3193720$e94ba560$@co.in> <7594FB04B1934943A5C02806D1A2204B1C37943B@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37943B@ESESSMB209.ericsson.se>
Date: Mon, 27 May 2013 21:58:06 +0530
Message-ID: <001701ce5af7$2ee19240$8ca4b6c0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOV9u/fklHpYO4tka0o0wHa47jypkTW/u2gACjmhCAA1ChYIABY7GggACIl4A=
Content-Language: en-us
X-CTCH-RefID: str=0001.0A0C0207.51A3899F.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] When a bundle offer is forked
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 May 2013 16:28:20 -0000

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