[Jingle] [Fwd: [Standards] UPDATED: XEP-0176 (Jingle ICE-UDP Transport Method)]

[Paul Witty]

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 
>> (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#appendix-B.9) 
>> 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.

-- 

Paul