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?). > 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. Coolio. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
