Re: [MMUSIC] BUNDLE: Splitting a BUNDLE

Suhas Nandakumar <suhasietf@gmail.com> Thu, 23 May 2013 08:17 UTC

Return-Path: <suhasietf@gmail.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 403B721F9377 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 01:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.673
X-Spam-Level:
X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
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 RikN5ZcJLLQz for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 01:17:52 -0700 (PDT)
Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id A764321F8E06 for <mmusic@ietf.org>; Thu, 23 May 2013 01:17:51 -0700 (PDT)
Received: by mail-qe0-f51.google.com with SMTP id nd7so1704316qeb.38 for <mmusic@ietf.org>; Thu, 23 May 2013 01:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XL7nG56jmM+fbEDwPvPnE/kzPd6EeVhTIwCw8xIJi+g=; b=NiXvNtgIlnxtm2JD/yBSXeZPucng+FcFErrqvNNKsIYVTZPBNDItt6TJzD4k6UEqrw lZjT4WJI95ei9KqNuAbCFV10I2UbHGH/s8zw86CMRn/I5L9cYz09WDsEfmp1vPNK4nsx hBFDXEBJSOShGwATHj92VafHaNyCg6TWYr1ueUTehQszwZUA03tScf86kG5rQRETv+tl zrPJUjUaragUUnU4nanJSBbxFpP4M6LUgc9LjLzfTbw+okYAb3Ek7Y2W3tMyWZP3rP0u MXHbHosDecy5tcW44YESdIwlRj3+imup0cgIufd9AYUCHR3U7ntJYTkZNklb7a8HkVV4 u3fQ==
MIME-Version: 1.0
X-Received: by 10.229.17.10 with SMTP id q10mr4107531qca.21.1369297071048; Thu, 23 May 2013 01:17:51 -0700 (PDT)
Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 01:17:50 -0700 (PDT)
In-Reply-To: <CAOJ7v-0OfJehPUtH33+r5O6Vjok9x7VrAB-a5tpPnzxNKMA3HA@mail.gmail.com>
References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> <519103E1.8030200@alum.mit.edu> <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB113508B39@xmb-aln-x02.cisco.com> <CAOJ7v-0OfJehPUtH33+r5O6Vjok9x7VrAB-a5tpPnzxNKMA3HA@mail.gmail.com>
Date: Thu, 23 May 2013 01:17:50 -0700
Message-ID: <CAMRcRGSJGOu8jeopjeDP3QO5EC4dXZ-_E84hHfPTnudcgN9EFg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=0015175cf92a8338a804dd5e516a
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE
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: Thu, 23 May 2013 08:17:56 -0000

+ 1
If the Answerer decides to move the m=line to a different BUNDLE group, i
support rejecting and re-offering than doing 1 or 2 above,

Thanks
Suhas

On Tue, May 21, 2013 at 3:41 PM, Justin Uberti <juberti@google.com> wrote:

> Agree completely. Otherwise media may show up at an unexpected port for
> the offerer.
>
>
> On Tue, May 21, 2013 at 7:52 AM, Cullen Jennings (fluffy) <
> fluffy@cisco.com> wrote:
>
>>
>> On May 14, 2013, at 6:01 AM, Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>> > Hi,
>> >
>> >>>> We seem to have an agreement that, when an SDP offer contains an m-
>> >>>> line associated with a bundle group, it is ok to leave that m- line
>> >>>> outside the bundle group in the SDP Answer.
>> >>>>
>> >>> Now, there has been some discussions about b>
>> >>> Yes, this is the conclusion I reached. I wish it weren't true. But I
>> >>> think there must be a mechanism for the new bundle to be rejected, and
>> >>> if it is first proposed in the answer then that isn't possible.
>> >>>
>> >>> IMO this is a rare enough case that suffering another O/A is
>> acceptable.
>> >>
>> >> I agree with Paul here.
>> >
>> > Me too :)
>> >
>> >> Allowing a new group (bundle) to be created in an answer is a much
>> larger deviation from RFC 5888 than allowing an m= line with a zero port to
>> be in a group, and the accept/reject problem can't be solved.
>> >
>> > Note that there are two cases:
>> >
>> > 1) A new bundle is created in the answer
>> >
>> > 2) An m- line is moved from bundle_x in the offer to bundle_y in the
>> answer. bundle_y was also present in the offer, so it is not created by the
>> answerer.
>> >
>> > In my opinion 2) should not be allowed either, as the m- line was not
>> present in bundle_y in the offer.
>> >
>>
>> Agree with you and to say more …
>>
>> I think that both 1 and 2 should *not* be allowed. There is no use case
>> to drive needing them and it is complicated. That can be done with a new
>> offer if needed.
>>
>>
>> > Regards,
>> >
>> > Christer
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>