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) as an optimisation which may allow you to connect sooner, a la Google Talk. FWIW, our Jingle implementation only implements the Google Talk compatible transport at the moment anyway, so we can meet any reasonable XEP modifications. We've got a full ICE implementation but we've not connected it up with our XMPP signalling yet. Hopefully within a month or two so we can do some interop testing. > Thanks! > > Peter Regards, Rob
