[Standards] Jingle: multiple candidates per transport-info?
robert.mcqueen at collabora.co.uk
Thu May 29 19:42:55 UTC 2008
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:
> 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
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.
More information about the Standards