On 06/04/2008 9:31 AM, Paul Witty wrote: > Peter Saint-Andre wrote: >> On 05/29/2008 1:42 PM, Robert McQueen wrote: >> >>> Peter Saint-Andre wrote: >>> >>>> Olivier Crête also wondered why in Jingle ICE-UDP a transport-info >>>> message is restricted to containing only one ICE candidate, rather than >>>> allowing multiple candidates: >>>> >>>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html >>>> >>>> Olivier pointed out that allowing a transport-info message to contain >>>> multiple candidates would be more consistent with the SDP offer/answer >>>> model, thus making it easier to write clients that support both Jingle >>>> and SIP as well as gateways between Jingle and SIP. However, it is my >>>> understanding that this approach would be inconsistent with the >>>> approach >>>> taken by Google Talk as well as any existing Jingle implementations. >>>> Therefore feedback would be appreciated regarding the implications of >>>> such a change. >>>> >>> It's not very hard for us to support both - our media engine tells us >>> when it's done gathering candidates so that we can generate SDP offers, >>> so similarly, we can generate a "one-shot" all-candidate offer. And, >>> processing several candidates received can easily be split up if >>> necessary. >>> >>> So I'd be in favour of making things more similar and allowing offers of >>> all of the candidates, and offering the ability to trickle candidates >>> (which I think the ICE RFC got rid of, but I've not checked recent >>> drafts) >>> >> >> Yes IIRC that went away at some point. >> >> >>> as an optimisation which may allow you to connect sooner, a la >>> Google Talk. >>> >> >> In VoIP people seem to care a lot about connecting sooner. :) >> >> If we don't allow this, then at least we may want to define how a >> gateway should handle trickled candidates (wait x seconds and bundle >> them?). >> >> > Trickling candidates is nice. If trying to use a TURN relay which is > for whatever reason not responding, we could wait a significant amount > of time before deciding that it will not respond, during which time an > aggressive ICE implementation could have already completed, having > chosen to use host candidates. I'd always favour trying to do things as > quickly as possible in order to provide a better user experience. > > I can't see any reason not to support multiple candidates in a single > message either; it's cleaner and less bandwidth heavy than sending > separate messages for each candidate, and gives us more information sooner.
I mentioned this to some of the Google Talk folks and they didn't have objections to allowing multiple <candidate/> elements per session-info message, so I will make that change to XEP-0176. However, you would still have the option of batching multiple candidates (even sending the complete list a la SDP) or trickling single candidates. So I think we need some guidelines on deciding when to batch and when to trickle. In fact we had some discussion about this a long time ago in the very early days of Jingle, IIRC. See for example: http://mail.jabber.org/pipermail/jingle/2005-November/000031.html Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
