[Jingle] Are We There Yet?
stpeter at stpeter.im
Thu Sep 25 12:19:12 CDT 2008
Robert McQueen wrote:
> I'm a bit behind on ICE, and particular how it turns up in SIP, but I
> also had a vague interop concern with XEP-0176, which is whether it has
> enough information in it that you can turn the ICE candidates into a
> SIP+ICE offer, and then deal gracefully with a SIP endpoint that doesn't
> understand the ICE parts? I seem to recall that SIP had ICE as extra
> lines in the offer, but that it also chose one of the most likely
> candidates to put in the "normal" place in case the other endpoint
> didn't do ICE. With XEP-0176, is there some way to reply to the ICE
> candidates to say that actually, you want to use just raw UDP on the
> wire, or does this actually rely on us doing a transport renegotiation
> to use the raw UDP transport XEP instead?
Here's how I see it.
Jingle clients are smart, so they use ICE (Google Talk does anyway, and
everyone wants to interoperate with Google Talk, right?). The Raw UDP
transport is like the "I'm feeling lucky" transport: you put in there
the candidate that you consider most likely to succeed. That candidate
is also the first candidate you'll send under ICE. So for
Jingle-to-Jingle communication I don't think we'll use Raw UDP at all.
Things are a bit more complicated for Jingle-to-SIP communication,
because as you point out the SIP endpoint might not do ICE. However, the
signalling is going to pass through a gateway. So IMHO the gateway needs
to have the intelligence to handle the case you mention. The scenario I
envision is this:
1. Jingle endpoint sends session-initiate with ICE-UDP transport.
2. Gateway forwards request to SIP endpoint.
3. Gateway determines that SIP endpoint doesn't do ICE.
4. On behalf of SIP endpoint, gateway sends content-add to switch
transport from ICE to Raw UDP and content-remove to get rid of the
ICE-UDP transport. Probably this means that the gateway will function as
a media relay, so it knows that the candidate it proposes will work.
Simultaneously, gateway sends appropriate SIP re-INVITE to SIP endpoint.
5. Jingle endpoint accepts use of Raw UDP, SIP endpoint accepts
re-INVITE, and everyone uses the gateway's media relay.
Maybe this can be simplified (if the gateway has capabilities
information about the SIP endpoint, it can immediately switch from
ICE-UDP to Raw UDP without discovering the lack of ICE support on the
SIP side "the hard way").
Or maybe this is unrealistic -- will Jingle-to-SIP gateways really run
media relays for use by older SIP endpoints? I don't know enough about
the SIP side of the equation to say that definitively.
Anyway, that's how I see it right now -- I'm quite open to being
More information about the Jingle