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

[[e-mail] (Dale R. Worley)]

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