[Jingle] [Fwd: [Standards] UPDATED: XEP-0176 (Jingle ICE-UDP Transport Method)]
paulrw at codian.com
Thu Feb 19 05:15:54 CST 2009
Olivier Crête wrote:
> On Wed, 2009-02-18 at 16:03 +0000, Paul Witty wrote:
>> I was having a bit of a think over that, and I don't think we ever need
>> to signal the remote candidates. It's designed to eliminate a race
>> condition when sending an updated offer
>> (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#appendix-B.6), but
>> the reason for the updated offer in SDP
>> doesn't apply to Jingle.
> So your Jingle->SIP gateway doesn't need it either ?
No; we route all the media through the gateway so that we can intercept
the STUN messages and do ICE on the Jingle side ourselves, with no
support for signalling ICE on the SIP side. We plan to have ICE for SIP
in the future, at which point the updated offer could come in useful so
we can let the two sides negotiate ICE between themselves. I can't,
however, see the use for remote-candidates when not interworking with
SIP; Jingle is designed to have no server awareness, but the only
entities (aside from the two ends) which would be able to see the remote
candidate information would be the servers, because of the use of TLS.
More information about the Jingle