Re: [MMUSIC] Bundle offer with different ports - where to expect media?

Christer Holmberg <> Mon, 20 May 2013 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ADB221F9362 for <>; Mon, 20 May 2013 06:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.096
X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 UNxLAy85Z5Yo for <>; Mon, 20 May 2013 06:50:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A7A9D21F93BD for <>; Mon, 20 May 2013 06:50:26 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fe36d000007102-da-519a2a206abf
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 90.01.28930.02A2A915; Mon, 20 May 2013 15:50:25 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 20 May 2013 15:50:24 +0200
From: Christer Holmberg <>
To: Emil Ivov <>, Paul Kyzivat <>
Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media?
Thread-Index: AQHOVWB8Vf53INw5HECYIT7hHOkqvpkOFr2g
Date: Mon, 20 May 2013 13:50:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra6i1qxAgzUdbBZrdk5gsZi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj/9vAgOYo7hsUlJzMstSi/TtErgynp74zVTwS7Xi7rwVTA2M zXJdjJwcEgImEgevvWCBsMUkLtxbz9bFyMUhJHCYUeLgpPtQzhJGiS2H7gBVcXCwCVhIdP/T BmkQEXCVeHzjFRuIzSwgIzHjbCMTiC0sECRx5+1mVoiaYImJ23ayQdhGEneOX2IHsVkEVCVm nJ/HDGLzCvhKfGi5ww6x6y+TxMz+mWDNnAKBEkd+zQezGYGu+35qDRPEMnGJW0/mM0FcLSCx ZM95ZghbVOLl43+sIHdKCChKLO+XgyjXk7gxdQrUndoSyxa+htorKHFy5hOWCYxis5BMnYWk ZRaSlllIWhYwsqxiZM9NzMxJLzfcxAiMmoNbfuvuYDx1TuQQozQHi5I4b6/21EAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjEZrlfsPZbx0d3tdu+5uUGfxYl7uubrXnmqfPOtvYSAVNmuC JMPeg7eCRYTXG3OH6oi0/yh7avFikoBt3CcVR6f+CUeeLX0hvr15Fv/DVjOlAu4nOf8ePJIQ 2LFczcTIrvUvl+eOg2vv1S1dov318J3m35Gmtztb9x6Ln7f6+BN5I4VmVaXLU5VYijMSDbWY i4oTAc5cf4doAgAA
Cc: mmusic <>
Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media?
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, 20 May 2013 13:50:38 -0000


> What happens when the offerer knows the answerer has bundle support, sends all m-lines with the same port, then the answerer 
> splits the first line away from the bundle? Would the answerer still send everything to the same port?

We discussed this week, and the outcome (at least my read of it :) was that the answerer is not allowed to split any m- lines away from the bundle in this case. Instead the answerer will have to send a new offer for the split, allowing new ports to be negotiated at both ends.



If so, I don't see why it should be different in the case where the offerer could not make the assumption about the bundle support.
--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <> wrote:
I agree with Christer's analysis here. The bundle port must be one associated with an m-line that is accepted, and included in the bundle, in the answer. That means the bundle port may not be the one from the first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive bundled media on any of the ports listed in the offer.


On 5/20/13 9:27 AM, Christer Holmberg wrote:
Agree with Emil but think maybe the question was meant to be on which
port(s) it needs to be able to receive bundled media.

This is covered by the last para in section 6.3 which states that the
answerer MUST use the port and everything else relating to the 1st m=
line. So far I thought this to be reasonable and even if the 1st m=
line is rejected this can still be the bundle port.


I agree that is what the spec currently says.

But, again, the following can happen:

1) The answerer rejects the 1st m- line; or

2) The answerer accepts the 1st m- line, but removes it from the bundle group. Yes, in this case the answerer WILL send media on that port, but ONLY media associated with that m- line (as it is no long part of the bundle group). The media associated with the remaining m- lines in the bundle group has to be sent somewhere else.

Again, once the second offer has been sent, the "bundle port" is explicitly signaled (as each m- line in the bundle group uses the same port number).



-----Original Message----- From:
[] On Behalf Of Emil Ivov Sent: 20 May
2013 13:13 To: Christer Holmberg Cc: Subject:
Re: [MMUSIC] Bundle offer with different ports - where to expect

Hey Christer,

On 20.05.13, 14:43, Christer Holmberg wrote:

Currently BUNDLE defines that the first offer is sent with separate
numbers (later, if the answerer has indicated support of BUNDLE, the
offerer will send a second offer, with identical port numbers).

Some people have indicated that the offerer shall be able to receive
data already when the first offer has been sent. The question is on
which port(s) it needs to be able to receive media.

Do we really have a choice here? We send the offer with different
port numbers so that it would work with endpoints that have no
knowledge of bundle. Such endpoints can start streaming media to any
port. Bundled devices can, on the other hand, start streaming media
on the bundle port.

So in other words, the offerer need to expect media arriving on any
port just as it needs to expect any stream arriving on the bundle

This would be consistent with what we do for rtcp-mux.


-          Some have suggested the port of the first non-zero m-
line within the offered bundle group.

-          Some have suggested ANY port

The issue with assuming the first non-zero m- line is that the
in the answer may reject it (put the port to zero), or remove it
from the bundle group (which people seem to want to allow). In both
would be strange to assume the first m- line.

Now, in case e.g. ICE is used, the offerer will be able to send the
second offer before any media is received to begin with. But, the
offerer could still receive STUN connectivity checks on any of the
ports, until the second offer has been sent.

We need text in BUNDLE about this, so comments/inputs are welcome



_______________________________________________ mmusic mailing list

_______________________________________________ mmusic mailing

mmusic mailing list