Subject: [Sip] RE: Jabber VoIP specs

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jan 2006 09:31:57 -0800

> Hi Dean, Everyone,
>
>
> Dean is correct.  To interoperate with SIP, the Jingle client 
> needs to use burst mode (which I believe is mandatory to 
> implement). 

Neither Burst nor Dribble are mandatory according to:
http://www.jabber.org/jeps/jep-0166.html#protocol-negotiate-modes
which says only:

  "An implementation SHOULD support both modes: dribble and burst."

Failing to declare a mandatory-to-implement mode will cause 
interoperability problems with Jingle clients, not to mention with
SIP.

To interoperate with IETF's ICE, Jingle clients need to support 
Burst.  I suggest that jep-0166 make Burst mode mandatory to 
implement.

> Below is 
> the best information I have based on personal discussions and a 
> conference call about two weeks ago with the authors.
> 
> The idea is to use dribble mode only when a Jingle client is 
> talking to 
> a single instance (a fully qualified JID) that also supports dribble 
> mode (presumably discovered when subscribing to presence 
> information).  
> The motivation (primarily from Google) for dribble mode is to try 
> candidate-pairs that give the best bang for the buck (STUN and local 
> addresses), before fetching relay-derived addresses that will 
> often go 
> unused.  In dribble mode, additional candidate pairs (for 
> TURN or other 
> relays) can be sent without waiting for any sort of lock-state 
> synchronization.
>
> To interoperate between a Jingle client and a non-ICE SIP UA, the 
> most-likely candidate would get mapped to the m-line.  To 
> interoperate 
> with ICE-enabled UAs, a Jingle client could either gather a larger 
> number of candidate pairs in the initial burst (local, STUN, 
> TURN relay 
> with UDP, TURN relay with TCP, relay using TLS, etc..), or send a 
> relatively short burst that is likely to work (ex: STUN, local) and 
> then do the equivalent of an UPDATE (allowing the offer-answer state 
> machine to be in an appropriate state) if a new burst of additional 
> pairs is needed (incrementing the ICE generation counter).  There are 
> several ideas of what to do in interop situations, but the details 
> still need to be worked out.

Ignoring interop for a paragraph or two ....

A question I have about Jingle's dribble mechanism is how a client
would know that it should get some TURN-derived addresses and
Dribble them?  That is, does it first send two candidate addresses
(local address, STUN address), wait <some number of> seconds, and
then get a TURN-derived address and Dribble that address?  

I'm curious if that's the technique, and how the value of <some 
number of> is obtained.  Perhaps that could be useful for ICE to 
consider for SIP.  

As to sending UPDATE to interoperate between a Dribble client and
a SIP client, that is interesting but I don't believe anyone has
considered what it would do to an already-running ICE state
machine, especially as the newly-added TURN address would be
on the m= line (because TURN is most likely to work it gets stuck
on the m= line) and not on an additional candidate on the
a=candidate line -- at least, per ICE's intention today.  Of
course, today, nobody has specified how UPDATE would work
in conjunction with ICE.

> A few folks, including myself, have pointed out some parts of the 
> Jingle spec that are not quite in-line with ICE.  The authors 
> are aware 
> that there is some work to do and assured me they want Jingle to 
> interoperate cleanly with SIP+ICE.  One of the authors told 
> me he would 
> like to wait until the next rev of ICE (-07) comes out before 
> committing new changes to Jingle.

That's fair.

> The Jabber Foundation also plans to write a SIP/Jingle gateway 
> specification, through their JEP process.  I'm sure there will be 
> plenty of opportunity for the SIP community to review and 
> contribute to this gateway spec.

I am confidant that we can interop SIP and Jingle signaling.

It is endpoint interop that is most important; without that, 
we'll be forced to use media relays to interoperate between 
SIP and Jingle.  Media relays, bad.

-d

> thanks,
> -rohan
> 
> 
> > -------- Original Message --------
> > Subject: Re: [Sip] Jabber VoIP specs
> > Date: Sat, 24 Dec 2005 21:44:10 -0600
> > From: Dean Willis <[email-masked]>
> > To: Dan Wing <[email-masked]>
> > CC: [email-masked], [email-masked]
> > References: <[email-masked]>
> >
> > If I'm reading this right, interworking between SIP and Jabber using
> > ICE is going to require "burst" mode in the Jabber implementations
> > every time. Without it, interworking failure appears to be 
> very likely.
> >
> > This is a good point. Anybody here working on the jingle stuff and
> > can get a change made? Rohan?
> > --
> > Dean
> >
> >
> > On Dec 22, 2005, at 8:10 PM, Dan Wing wrote:
> >
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of [email-masked]
> >>> Sent: Friday, December 16, 2005 1:11 PM
> >>> To: [email-masked]
> >>> Subject: [Sip] Jabber VoIP specs
> >>>
> >>>
> >>> For those that may not have seen this, the Jabber Foundation
> >>> has published their VoIP signaling and media encoding specs.
> >>> These specs have been reconciled with Google Talk if I read
> >>> the introductory comments correctly.  I'd be interested in
> >>> any discussion of the design of these protocols by the SIP
> >>> gurus here...
> >>
> >> Thanks for mentioning the specifications.
> >>
> >>> http://www.jabber.org/jeps/jep-0166.html
> >>
> >> This specification describes a 'dribble' mode and a 'burst'
> >> mode to exchange endpoint candidate addresses.  Only
> >> 'burst' mode is compatible with ICE (draft-ietf-mmusic-ice).
> >>
> >> Section 6.5.2 says that both modes are only SHOULDs.
> >>
> >> If we want to have compatibility with Jingle, they'll have
> >> to make 'burst' mode a MUST.
> >>
> >> -d

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip