Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00

Christer Holmberg <> Fri, 19 April 2013 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3365921F9457 for <>; Fri, 19 Apr 2013 02:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.171
X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bodWjN4JG2Tm for <>; Fri, 19 Apr 2013 02:13:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 56D3E21F8746 for <>; Fri, 19 Apr 2013 02:13:12 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-de-51710aa7d525
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 31.01.19728.7AA01715; Fri, 19 Apr 2013 11:13:11 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 11:13:10 +0200
From: Christer Holmberg <>
To: "" <>, "" <>, "" <>
Thread-Topic: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00
Thread-Index: AQHOO6+0f07p9UcwxEeKXZ4+ipCSTJjcFsQAgAEV1pA=
Date: Fri, 19 Apr 2013 09:13:09 +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+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre5yrsJAg5ePZCzO/13EZjF1+WMW i5cnyhyYPSbv/8rssWTJTyaPu7cuMQUwR3HZpKTmZJalFunbJXBlrD/SylzQq17xc+t91gbG 0/JdjBwcEgImEqdfpnYxcgKZYhIX7q1n62Lk4hASOMwo8f3kSRYIZzGjRMOkY4wgDWwCFhLd /7RB4iICvYwS61smMoF0Cws4S5zb8JcFxBYRcJHYubmPCcK2klh0oocRxGYRUJU4NnsNG4jN K+ArsefMdVYQW0jgC6PE20UpIDanQITEmlWLwOYwAl30/dQasDnMAuISt57MZ4K4VEBiyZ7z zBC2qMTLx/9YIWxFiavTl0PV60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0 zELSsoCRZRUje25iZk56udEmRmB0HNzyW3UH451zIocYpTlYlMR5w10vBAgJpCeWpGanphak FsUXleakFh9iZOLglGpglH19oNKD22j9HGcB/+mnWXR2HYrkX7kxulbi7dH4GgPN3a0bqmf8 XaoV9fhv2+dV4synsxQUjy6RP2bLM0HpepyOspDQir1hk3a89b/polsjceHzNL7FSk+UI38L cAQVN+SX5Hd/jJS+9nDyk4MhtxQiYhkDHy/Xn6XR//pVeDuPR16LY+R3JZbijERDLeai4kQA KFHvjlwCAAA=
Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00
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: Fri, 19 Apr 2013 09:13:15 -0000


> I also reviewed the draft and was trying to understand what problems it is trying to solve. It is easier to find a solution if we 
> agree on the requirements. From the draft I gathered that it tries to address at least these two limitations in [1]:
>   A problem with the existing bundling proposals is that it does not
>   appear possible to create a single initial offer that will allow
>   bundle to be negotiated but maintain interworking with bundle unaware
>   implementations and therefore it is necessary to perform an initial
>   offer/answer exchange which does not fully describe or at least only
>   implicitly describes what the offerer really wants to offer.  The
>   existing bundle proposals also don't take account of the fact that
>   when both parties support ICE [RFC5245] the port in the m-line of the
>   initial offer may not be used at all, for example due to a dual stack
>   offer endpoint offering IPv4 and IPv6 addresses in parallel.

The fact that you may end up not using the port in the m- line is normal ICE procedures. But, I do agree that we should add some text about that.

> Markus: This is a relevant point if indeed call setup time or even the number of messages can somehow be reduced in some of the 
> situations. But is that the case here? I think that if both peers support bundle (as in [1]), they can start bundle-related connectivity checks 
> immediately, and do not need to do any other connectivity checks. Is there a substantial difference in this regard?
> 2.)
>   Also the existing bundle proposals have not considered some of the
>   more complex ICE scenarios involving multiple candidates.  For
>   example when an SDP m-line contains multiple ICE host candidates
>   during dual stack negotiation, the candidates cannot be considered
>   equivalent with regard to bundling with candidates on in another
>   m-line and therefore some way of indicating which candidates can be
>   bundled seems to be desirable.  This could be achieved by including
>   the complete bundle transport address (IP and Port) in the candidate
>   or by providing some kind of bundle linkage within the ICE candidate
>   lines.
> Markus: This seems to support exotic situations like that the offerer would be willing to bundle over 
> IPv6, but not over IPv4. Personally I'm not sure if there are good real use cases for this type of capability. 
> Any concrete ideas where this would be useful?

I don't really think we need to consider this. If an endpoint wants to change its candidates, e.g. based on whether bundle will be used or not, it can send a new offer, with new candidates.




-----Original Message-----
From: [] On Behalf Of ext Dale R. Worley
Sent: 18 April, 2013 00:07
Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00

It seems to me that the essence of
draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE candidates to effectively specify two address/ports that is available for the remote UA to contact this UA.  One address/port is the standard ICE address/port and the other is the "bundleport", and indicates an address/port that the remote UA can contact using bundled/multiplexed media.

If the candidates for two different m= lines specify the same bundleport, it would be useful to define the ICE procedures to ensure that connectivity to that address/port is tested only once for any remote address/port.  If the remote UA is not bundling/multiplexing, this does not change anything, as connectivity has to be tested separately for each transport association (5-tuple).  But if both ends are using bundling, we could have 3 m= lines for each UA, but only effectively one set of candidate address/ports at each end.  We wouldn't want to repeat the connectivity checks 3 times over.

Also, what is the order of testing of ICE candidates if bundleport is present?  My understanding is that ICE was carefully designed so that both UAs test each candidate pair simultaneously.  What is the timing/sequencing rules when bundleport is present to ensure that (1) both UAs test each pair simultaneously, (2) the bundleport address/ports are tested first if both ends support bundling, and (3) the timing of "baseline" candidate testing is unchanged if either UA does not support bundling?  It seems like we need a careful specification of the changes to the candidate testing algorithm.

mmusic mailing list
mmusic mailing list