Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between

Christer Holmberg <> Mon, 27 May 2013 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A10C221F9617 for <>; Mon, 27 May 2013 07:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.364
X-Spam-Status: No, score=-5.364 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iU-Mzv03ferJ for <>; Mon, 27 May 2013 07:33:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1F7A821F93EC for <>; Mon, 27 May 2013 07:33:40 -0700 (PDT)
X-AuditID: c1b4fb30-b7f8a6d000001a2d-c4-51a36ec315d6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 23.DE.06701.3CE63A15; Mon, 27 May 2013 16:33:40 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 27 May 2013 16:33:39 +0200
From: Christer Holmberg <>
To: "Cullen Jennings (fluffy)" <>, Paul Kyzivat <>
Thread-Topic: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between
Thread-Index: Ac5YZ89eNSNKdC6FQhCoA7qw0p8XLAAE3h6AAJTS/oAABfqb0Q==
Date: Mon, 27 May 2013 14:33:39 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre6RvMWBBtsmc1p0TGazmLr8MYvF ig0HWB2YPf6+/8DkMeX3RlaPJUt+MgUwR3HZpKTmZJalFunbJXBlXF3+m6Xgs1TF0kkbmRoY e0S7GDk5JARMJL6/PckEYYtJXLi3nq2LkYtDSOAwo8TvtfMZIZwljBK393xg7WLk4GATsJDo /qcN0iAiECnxfuF+dpAws4C6xNXFQSCmsECyxJYP+RAVKRLHF99ihbCdJKatWc8OYrMIqErc efmHEcTmFfCV2LpqChPEpg2MEv/PrQJr4ARKzPy9mhnEZgS67fupNWB3MguIS9x6Mh/qZgGJ JXvOM0PYohIvH/9jhbAVJT6+2scIUW8g8f7cfGYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQ tMxC0jILScsCRpZVjOy5iZk56eXmmxiBMXNwy2+DHYyb7osdYpTmYFES59XnXRwoJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgXHD7bx7/c1L7m4/3q+YrHQj8PnaF6/y9OSWan+eOGXbmtzT phXyysp+Aiu2fDbzCljG9E+2rXBeRcaUlC9dDpK+ek+bptvo5yYatGxiDLt1ykVP/vn0TyLH Q/W9Y2WeGC+2Y+5mbC5TtTOP1HgtXJ0u8fT+lNmGZyYwMprPX3oo1ibktXz3TiWW4oxEQy3m ouJEAODenyVnAgAA
Cc: "" <>
Subject: Re: [MMUSIC] BUNDLE DECISSION: Full bundle or no bundle - there aint anything in between
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 May 2013 14:33:46 -0000


>I think a agree with Paul's text but I read it as almost the opposite of what you wrote.

We meant the same thing: the bundle port is the first mid value in the SDP group:BUNDLE attribute, and the first mid value in the SDP group:BUNDLE attribute must not represent a zero port m- line.

Paul talked about "the first mid representing a non-zero m- line", while I talk about having a rule saying that "the first mid must not represent a zero m- line to begin with"

> I think some examples would help

There will be lots of them :)

> So if the offer has 3 m-lines with A,B, C in a bundle with ports 1,2,3. It is fine for the answer to put m-lines A and B in a bundle both using port 1 but then have C outside the bundle using port 3. Do have this right? Would a detail example help ?

Yes, as long as the offer contains DIFFERENT ports, it is allowed to leave C outside.

But, if the offer contains IDENTICAL ports, it is not allowed to leave C outside, because there would be no "fallback" port for C. That is what rule #4, which you are pretty sure you disagree with, says :)



On May 24, 2013, at 8:36 AM, Paul Kyzivat <> wrote:

> I agree with the sense of what you state below.
> I have some nits with the words you use.
> On 5/24/13 6:28 AM, Christer Holmberg wrote:
>> Hi,
>> At the interim yesterday, we agreed that an answerer MUST always include
>> identical ports* (usage of port zero within a bundle is a separate
>> topic) for all m- lines within an bundle group.
>> If the answerer wants to use different ports* for some/all m- lines, it
>> MUST NOT include those m- lines in a bundle group
> OK so far. But:
>> (if they already are
>> in a bundle group, a separate offer is needed to remove them).
> This depends on what you mean by "already in a bundle group".
> Certainly they are already in a bundle group in the offer, so presumably that is not what you mean.
> I presume you mean that they were already in a bundle group in the prior O/A.
> I think this can be stated more clearly. How about:
> The answer to an offer containing a bundle group may remove an m-line from the bundle group if (and only if) the address/port of the m-line in the offer is distinct from the address/port of all the other m-lines in the offered bundle group. When doing so it must supply a unique address/port for that m-line in the answer.
>       Thanks,
>       Paul
>> WHAT IT MEANS: There is no way for an answerer to tell that the offerer,
>> for certain m- lines, can use the same port*, eventhough the answer will
>> use separate ports*.
>> I will work on some actual text proposal later, but please indicate if
>> you OBJECT to this approach in general.
>> Regards,
>> Christer
>> NOTE: “port” = port:address combination – we are working on coming up
>> with better terminology J
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list

mmusic mailing list