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

Hi,

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]:

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.

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?

[1] http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/

Regards,
	Markus

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Dale R. Worley
Sent: 18 April, 2013 00:07
To: mmusic@ietf.org
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.

Dale
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic