Re: [MMUSIC] When a bundle offer is forked

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Wed, 05 June 2013 00:22 UTC

Return-Path: <fluffy@cisco.com>
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 6B26A21F9A28 for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 dtMDE2mQtCXQ for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:22:03 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A447A21F9A26 for <mmusic@ietf.org>; Tue, 4 Jun 2013 17:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2593; q=dns/txt; s=iport; t=1370391723; x=1371601323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gH//XCVVZbb1fUZkPbO6flL/V2mmnUCTkqz32TPVc48=; b=CkA5QLupLaFGiz34zxz70QE1PUsvWUC/k/wOd0RwNovgK8eWicQl0uKz OdrdZT6xtc/uBS2klxmEDDIjhd6S8WberzK1TjH8fsu11unUWi2yK4Oom XqM0o8eNK1cvzsH1i1VQkKisKBtQe7nPpS/guzfNxOmN0tCIv9tNXSqVy I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FAOKDrlGtJXHA/2dsb2JhbABaDoJ7ML8qfhZ0giMBAQEDAQEBATc0CwULAgEIDgoKFBAnCyUCBA4FCId/Bgy9cwSOcQIxB4J6YQOof4JRPoIn
X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="218810858"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jun 2013 00:21:52 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r550LqNY008058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 00:21:52 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 19:21:52 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] When a bundle offer is forked
Thread-Index: AQHOYYKtP/NHv6FjPEKQrwlk8Mwd/A==
Date: Wed, 5 Jun 2013 00:20:30 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11354DACB@xmb-aln-x02.cisco.com>
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>
In-Reply-To: <519E530C.60705@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.232.182]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <54B9165676F06F4181BD4041A195E401@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
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: Wed, 05 Jun 2013 00:22:09 -0000

I don't think dealing with forking with bundle is any different that dealing with forking without bundle. The key thing is we are not using bundle with multicast. 

On May 23, 2013, at 11:34 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> 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:
> 
> * if the bundle is accepted by multiple forks, does this form
> one RTP session or several? If so,

same as if your were not doing bundle in O/A without multicast - they are different 


> 
> - if so, then if each fork accepts a different set of m-lines from
>   the bundle, how can that work with a single RTP session?

so they are not a single session but again, it's pretty much the same as if you were not using bundle and things the forks accepted different sets of m lines. 

> 
> * How does ICE work in this case? (Is that already covered by ICE,
> since it mostly isn't specific to bundle?

exactly the same as if you were not doing bundle but there are less ports to set up 

> 
> * If one fork adds/removes an m-line from the bundle, should that
> be mirrored to the other forks?

huh - no. I can't even imagine what this means. Think about this in a non forking case. A sends an offer with audio and video that forks to B and C. B replies accepting only the audio, C replies accepting both. A is likely to end up ending one of the forks all together but it's not like A tires to until the media from B and C. 

> 
> * ...
> 
> ISTM that the simplest thing we could do about this is put a statement in the draft that this draft does not specify behavior in the case of forking - that conforming devices are constrained to a single fork, and that behavior in forking cases could be a subject of future standardization.


Sorry but that won't work. I don't see any actual problem identified where bundle complicates the existing forking issues. 

When the devices creating the offer and offer bundle, it has no idea if that offer will end up being forked or not. 



> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic