Christer Holmberg <> Mon, 27 May 2013 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 729F321F967D for <>; Mon, 27 May 2013 10:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t7TCoAR-ozvg for <>; Mon, 27 May 2013 10:16:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4AACA21F9679 for <>; Mon, 27 May 2013 10:16:26 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fe36d000007102-f3-51a394e859c9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 57.6F.28930.8E493A15; Mon, 27 May 2013 19:16:25 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 27 May 2013 19:16:24 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Thread-Index: Ac5Yevnd5lghFfM/QmuiU1fEkjXC+QAAh7mAAI+mEfAACtXEAAAFeb+C
Date: Mon, 27 May 2013 17:16:24 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre7LKYsDDX4fY7aYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6Mj1d3shTsEK5YfP8hcwPjNP4uRk4OCQET iUX77rFD2GISF+6tZ+ti5OIQEjjMKHH+yHIWCGcJo8S1vgtAGQ4ONgELie5/2iCmiICGxKSt aiAms4C6xNXFQSBjhAWsJKYvmcYKYosIWEvcmN7OCGG7SXRNX80MYrMIqEp83XaZBcTmFfCV uDR3LRPEpouMEt/6roA1cApoSRxunw7WwAh02/dTa5hAbGYBcYlbT+YzQdwsILFkz3lmCFtU 4uXjf6wQtqJE+9MGRoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRlFpKWWUha FjCyrGJkz03MzEkvN9zECIyQg1t+6+5gPHVO5BCjNAeLkjivHu/iQCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MYcG7PnXKp3oaHtr3sMXdVar2WDpXvZ64vMsJi3ie+ZE73myarRV+5aac qqvSP19OziN/prwT/6RitdrZKTx3x9yC8LIni+ycju/cVdDwurWz4eGtkyKrSsNeChQuNXn+ S1/ridwK6bybYo2G15hO/ziq6pb2/dqSxmi2l6Wvtyd90DVmPmOlxFKckWioxVxUnAgAUy7i S14CAAA=
Cc: "" <>
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 17:16:36 -0000


>>>> At the interim yesterday, we agreed to use the SDP BUNDLE group
>>>> attribute to indicate on which port bundled media will be sent. In an
>>>> SDP offer, the order of the attribute mid values can be used by the
>>>> offerer to indicate a "wish", but the first attribute mid value in the
>>>> answer indicates where the answerer will eventually send bundled media.
>>> This could be interpreted to mean the first a=mid value in the SDP.
>>> I'm sure you mean "the first mid value in the a=group:bundle" line.
>> Yes.
>>> Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line.
>> In the draft "bundle group" means (or, at least is supposed to mean :) the bundle grouped m- lines, and in general I think it is better to explicitly mention the line/attribute.
>>> This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero
>>> port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing.
>> I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line.
> I just want to be sure we're clear here.
> Are you saying that even if we relax 5888 so that we may have m-lines
> with port zero in a bundle group, that the *first* mid in the bundle
> group can't designate a zero port???

Yes, for BUNDLE. It doesn't have to be a generic 5888 rule.

> I guess that should always be possible as long as there is at least one
> with a non-zero port.
> Do we have a possibility, with ICE, that all the m-lines in the bundle
> will have zero port? (Because we are waiting for ICE to figure out the
> actual port.) Or are we going to use something else for that purpose?
> As long as there is no possibility of having a bundle where all the
> ports are zero then I'm ok with what you propose.

I hear what you're saying.

But, in that case saying "first non-zero mid" does not work either, does it? :)

Another option is to also allow mids for zero-port m- lines to be first. A first mid for a port zero m- line would mean that there is no port for bundled media. Maybe there could be a use-case for that.