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

"Cullen Jennings (fluffy)" <> Tue, 21 May 2013 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7563321F9839 for <>; Tue, 21 May 2013 07:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.949
X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tFoNDeAGak2n for <>; Tue, 21 May 2013 07:38:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9E0F121F9832 for <>; Tue, 21 May 2013 07:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2918; q=dns/txt; s=iport; t=1369147114; x=1370356714; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L+7fNVfpeNV+H0eD30vHMTPkTr4ILy5A/2EJwmYc9S4=; b=EYrq/UTTI0li5F4HxGZwK9kmdXyVtbv5yhJM7FPdow84kYJYJCFb9N6z 5xQIS5ocBPdytJciQKZETY4qjyT5pEwzMzMt22BLPPAbeygA2UljTKWA2 QFKNcPwdKxTK+mlen++Ok734x6WwVaDUdERLXXbxz2Pe9/TL+mnZF1LLJ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwFAPGFm1GtJXG//2dsb2JhbABZgwgwwU+BCRZ0giMBAQEDAQEBATc0CwULAgEIIhQQJwslAgQOBQiHfwYMu0cEjmcCMQeCc2EDqHiDD4Im
X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208";a="213149478"
Received: from ([]) by with ESMTP; 21 May 2013 14:38:34 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4LEcYxA021150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:38:34 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 21 May 2013 09:38:33 -0500
From: "Cullen Jennings (fluffy)" <>
To: Christer Holmberg <>
Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media?
Thread-Index: AQHOVjDeOyx3rJlebkW/++Fqq1r23w==
Date: Tue, 21 May 2013 14:38:20 +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-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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: Tue, 21 May 2013 14:38:39 -0000

Let say Alice make an initial offer with there M lines with port 1 for video 1 and port 2 for video 2, and port 3 for video 3 and they are all in bundle. 

The semantics of O/A are that you must be prepared to receive anything you offered as soon as you offer it.  So for this to work, Alice has to be receiving on any combination of ports that would be valid in any possible answer. ( I think everyone else on this thread came to same conclusion so just agreeing and summarizing) 

So the interesting cases is an if the answer rejected the video 1 and accepted the video 2 and 3 with theses two bundled. I think that results in saying that you have to be able to receive on any port. 

This has impact for when the PT overlap and you don't know the SSRC yet. For that case, given Alice is the one that created the PT used for each m-line, I think that is just OK. That goes to the demux conversation. 

I don't know what people mean by splitting a bundle but I think one should be able to reject m lines inside a bundle, including the first m line, but I don't think there is a need to take offer lines 1,2,3, 4,5,6 in a bundle and have the answer put 1,2,3, in one bundle and 4,5,6 in a second bundle. So if that is what we mean by splitting bundle, I don't think we need it. But we do need to be able to reject m lines inside a bundle. 

On May 20, 2013, at 5:43 AM, Christer Holmberg <> wrote:

> Hi,
> Currently BUNDLE defines that the first offer is sent with separate port 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.
> -          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 answerer 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 cases it 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 :)
> Regards,
> Christer
> _______________________________________________
> mmusic mailing list