[Jingle] XEP-0176 - putting many candidates in initiate/accept

Justin Uberti juberti at google.com
Wed Apr 8 15:47:06 CDT 2009

Using transport-info allows calls to start much more quickly, since you can
send basic local candidates first, and then stun/relay candidates as the
appropriate servers respond. Also, other candidates may become available
during the call. So we definitely want to use transport-info when possible;
the only case where we know this will be a problem is for SIP interop.
I'm fine with the change that you propose, I just hope that it's only used
when necessary.

On Tue, Apr 7, 2009 at 5:34 PM, Justin Karneges <justin at affinix.com> wrote:

> There was a recent change to suggest putting all of your candidates in
> initiate/accept.  Peter says this was to help simplify the state machine.
> However, transport-info is still in the XEP and expected to be supported,
> so
> I don't see how this resulted in any simplification.  I just wanted to
> point
> out that if anyone is planning to write a client that doesn't understand
> transport-info (/me looks at whoever suggested this change), compatibility
> will be lost.
> There seems to be a way to indicate that you prefer all candidates in the
> initiate/accept: the urn:ietf:rfc:3264 feature, originally intended for SIP
> gateways.  I suggest simple clients advertise that feature too, then, and
> when interacting with a client that supports it you MUST send all
> candidates
> in one pass and never use transport-info (instead of the "SHOULD" wording,
> which may imply that it cannot be relied on).
> -Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jingle/attachments/20090408/54113927/attachment.htm 

More information about the Jingle mailing list