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

Emil Ivov <> Mon, 20 May 2013 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15A2D21F9048 for <>; Mon, 20 May 2013 07:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sFiRdFSjsBkH for <>; Mon, 20 May 2013 07:51:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4008:c01::232]) by (Postfix) with ESMTP id F3CD721F8976 for <>; Mon, 20 May 2013 07:51:50 -0700 (PDT)
Received: by with SMTP id ik5so3594385bkc.37 for <>; Mon, 20 May 2013 07:51:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=TdtGtUAM76dYwtjC2rtPSt7oxJahgz7QH01VNtyyZ/s=; b=laM02aE3sxi0IEnPsMnZorXCuhUV1LlLmc+/yZVFcjJcvKLbn4qGcddK2d1oIFYJ1u muqe7clLoeBmk263BBxbovWb/wYphFDwN4e2krSIJw4qH/KRU2Vjg9/pMWfjvihImh1x SVyxzI7FPBp+MhyQ4Q7NEligW2Au1R39S+I+/dXI93jbmZ7IsKOtum2lrzSHdaobaHVg ++xjxKCYPscrMQ09aYtCUECtNO7A3xAUR5u25fSs9uDZisP4XyvU7k7OAyk/xDDQsz90 sSptZWRbvmln8RVgbac4yG+iC//oASukCD/ckbv3qNsHCFgwTKVJU1nsYVlLlVUJJu84 wVLQ==
X-Received: by with SMTP id b8mr19847022bkc.83.1369061509769; Mon, 20 May 2013 07:51:49 -0700 (PDT)
Received: from camionet.local ([]) by with ESMTPSA id kn5sm5850960bkb.20.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 07:51:48 -0700 (PDT)
Message-ID: <>
Date: Mon, 20 May 2013 17:51:47 +0300
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Christer Holmberg <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnEdR9SoiTrHKwRpPUo8Y9rs9bheVm5lyYyexFHSBEwmrkM+q6hvGmfa3kE1gp3OW1j7rze
Cc: mmusic <>, Paul Kyzivat <>
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 14:51:53 -0000

Hey Christer,

On 20.05.13, 17:16, Christer Holmberg wrote:
> Hi,
>>>> 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,
>> Yes, sorry, I didn't follow this closely.
>>> 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.
>> OK, so shouldn't the same thing happen in the case with different
>> ports?
> I suggested that it should never be allowed to split an m- line from
> a bundle group in an answer, but others had other opinions.

I don't see how we could allow it in one case and disallow it in the
other. The only difference between the two cases is how informed the
offerer is about the answerers bundle support capabilities and I don't
really understand why this would influence the decision to allow
splitting bundles one way or the other.

> HOWEVER, it would still not help in the case where the 1st m- line is
> rejected.

Well, how about looking at it this way: the offerer specifies a bundle
port in the first m=line. This also happens to be the port for the first
media line but the two are different things and just happen to have the
same value for reasons related to syntax and convenience.

A bundle supporting answerer should understand this. After receiving the
offer that answerer has learned the bundle port number. Rejecting the
first m=line in the answer does not change this.

Of course the answer would come with the first m=line having a 0 port
but the offerer would then just learn the bundle port number at the
first m=line with a non-zero port.

Subsequent offers and answers would all use that same m=line for the
bundle port.

Does this make sense?


> Regards,
> Christer