Christer Holmberg <> Thu, 02 May 2013 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB85A21F8FB3 for <>; Thu, 2 May 2013 10:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.169
X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8svaiXcrelMG for <>; Thu, 2 May 2013 10:42:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA06021F90F1 for <>; Thu, 2 May 2013 10:42:10 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f536d000006e05-8c-5182a5715ce5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C0.94.28165.175A2815; Thu, 2 May 2013 19:42:09 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Thu, 2 May 2013 19:42:09 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>, "" <>
Thread-Index: Ac5HLpsHDAej8eBpR9CrVaLIOw2gaQABOGUAAAoQgo8=
Date: Thu, 02 May 2013 17:42:08 +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+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrW7h0qZAg+5v5hZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxW2TlFhSFpyZnqdvl8Cd8a5tH2vBapmKmzP7mBsY14h1MXJwSAiY SCz+m9zFyAlkiklcuLeerYuRi0NI4DCjxI3dS1ggnMWMEmv2bWEFaWATsJDo/qcN0iAi4Cvx 7PFtNhBbWMBAor35MiNE3FDi4MKD7CDlIgJWEv96IkHCLAIqEqeevmUFsXmBWp/e+skMYgsJ 5Eos+fqKBcTmFNCRuHb0C9gYRqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4V4 RVFieb8cRLmBxPtz85khbG2JZQtfM0OsFZQ4OfMJywRG0VlIps5C0jILScssJC0LGFlWMbLn JmbmpJcbbmIExsHBLb91dzCeOidyiFGag0VJnDeJqzFQSCA9sSQ1OzW1ILUovqg0J7X4ECMT ByeI4JJqYGT8+N8sbMWV+t/ON38k6HBs/FRtqCvTZzLhpe7C/QZnji1ex9weqV517ldNY9KJ KZuiejb5B3lx8K6sWXhsSoppsUpWXqKGgejZQDsNxp7VK+JEmy+azdH6vqtUjfX9959/lBJn 7fmmLF17MLX8/Sa97hLPzqOisdfmsj6/f1eYM/7Y1oM9IkosxRmJhlrMRcWJAPNtac5WAgAA
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: Thu, 02 May 2013 17:42:22 -0000


> I think what you suggest should work.
> An implication is that you can't signal how you would like to bundle a
> hypothetical m-line (currently with port zero) were it to subsequently
> be offered with a non-zero port. I think that is ok.

I was thinking about that also, and if someone can come up with a reason why it would be needed I'd like to hear it.

And, IF there is a good use-case, we could e.g. define an SDP media level attribute for indicating such thing.

m=audio 0 ....
a=maybe-I-want-to-be-part-of-the-following-bundle-group: BGROUP1

> My take has always been that the mechanism of signaling a
> rejected/unused m-line with a zero port was intended to imply that none
> of the accompanying media section lines need to be valid, and ones that
> otherwise might have been required are not required in this case. That
> is necessary so that an answerer can successfully refuse an offered
> m-line that it doesn't understand, and so can't construct a consistent
> answer. So the recipient must be very tolerant about what it receives in
> this case. That means it isn't appropriate to specify *anything* about
> what goes into the media section of a rejected m-line.

Agree. Good point.



On 5/2/13 8:55 AM, Christer Holmberg wrote:
> Hi,
> One of the open issues is the usage of m- lines with port value zero
> within a BUNDLE group.
> As Paul has indicated, RFC 5888 does not currently allow it.
> One suggestion has been to update RFC 5888. But, before we go down that
> path, I think we need to see whether NOT allowing zero port m- lines in
> BUNDLE groups would work.
> So, how would it impact BUNDLE?
> Zero port value in answer:
> If an m- line in the offer contains a non-zero port value, but the
> associated m- line in the answer contains a zero port value (read: the
> answerer rejected the offered media associated with the m- line), the
> number of m- lines associated with the BUNDLE group would differ in the
> offer and answer.
> As the media is rejected, no matter whether it would be part of a BUNDLE
> group or not, I can’t think of any issues.
> Zero port value in offer:
> If an m- line in the offer contains a zero port value, the associated m-
> line in the answer MUST also contain a zero port value.
> If the m- line has previously been part of a BUNDLE group, with a
> non-zero port value, it means that the number of m- lines in the BUNDLE
> group will be reduced. But, again, as the media is rejected, no matter
> whether it would be part of a BUNDLE group or not, I can’t think of any
> issues.
> Then, if one later wants assign a non-zero value to the m- line, and
> insert it into a BUNDLE group, the number of m- lines in the BUNDLE
> group would increase. I don’t see any issues as such with that. One
> question, however, is whether the answerer is allowed to accept the m-
> line, but reject it being part of a BUNDLE group. But, let’s discuss
> that in a separate thread.
> My suggestion is that we do NOT allow m- lines with zero port value in a
> BUNDLE group. Please indicate whether you are aware of restrictions, or
> problems, that this would bring, and we will document those.
> Regards,
> Christer
> _______________________________________________
> mmusic mailing list

mmusic mailing list