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