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

["Hutton, Andrew" <[e-mail]>]

Comments below.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Christer Holmberg
> Sent: 19 April 2013 10:13
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: 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.
> 
> 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.

[AndyH] - I agree.

> 
> > 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?

[AndyH] - No. The difference is only that everything relating to the candidate is explicit within the candidate line which makes it more readable and less prone to errors.

> >
> > 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.

[AndyH] I am not so convinced and not sure I understand the comment about changing the candidates with a new offer. If anybody wants to specify a bundle where it is only possible to bundle some candidates and not others then we would not have a way of doing this. The bundle over IPv6 but not IPv4 is one case but more likely it could be that say host candidates can be bundled but not relay candidates. 


> 
> Regards,
> 
> Christer
> 
> 
> [1] http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-
> negotiation/
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of ext Dale R. Worley
> Sent: 18 April, 2013 00:07
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic