[Standards] Enabling Jingle calls to non-subscribed JIDs with directed presence

Simon McVittie simon.mcvittie at collabora.co.uk
Wed Jan 13 19:05:28 UTC 2010

On Tue, 05 Jan 2010 at 17:28:15 +0000, Simon McVittie wrote:
> I'm trying to pick up some earlier work on making Jingle calls work for JIDs
> to which the caller isn't subscribed.

I've written up the proposed API as a proto-XEP and submitted it to the


XML is available here (click "raw" for raw XML):


> > <presence from='peter at jabber.org/foo' to='paul at jabber.org'>
> >   <c xmlns='http://jabber.org/protocol/caps'
> >    hash='sha-1'
> >    node='http://psi-im.org'
> >    ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
> >   <decloak xmlns='urn:xmpp:decloak'/>
> > </presence>

This is essentially what I've done. For the moment my proto-XEP uses a
vendor-specific XML namespace, because I developed it alongside a test
implementation (telepathy-gabble).

> > <presence from='paul at jabber.org/bar' to='peter at jabber.org'>
> >   <c xmlns='http://jabber.org/protocol/caps'
> >      hash='sha-1'
> >      node='http://www.chatopus.com'
> >      ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
> >   <decloak xmlns='urn:xmpp:decloak'/>
> > </presence>

To avoid infinite loops (or having to do complex state-tracking to prevent
them), the reply is just directed presence - it omits the <decloak/> element.

> However, it was pointed out in August 2008 that GTalk (at the time) would only
> let <presence type='subscribe'> packets through to its users, so the de-cloak
> request might have to look more like this[3]:
> > <presence type='subscribe'>
> >     <temporary/>
> > </presence>

I haven't done this; discussing with my colleagues, we decided that if GTalk
explicitly wants to suppress communication from unapproved entities to its
users, we should respect that.

> * After asking for directed presence, how do we tell whether there'll ever be
>   a response? An arbitrary timeout seems like the only useful answer...

My test implementation just waits 5 seconds.

> * If Bob has configured his client to make this work "silently", then Alice
>   can determine that Bob has a client logged in, which client it is, and its
>   resource name (but not whether it is available/away/dnd/..., and no
>   "rich presence" like geolocation, avatar, etc.) - a (user-configurable)
>   presence leak

My test implementation signals to the UI that Alice has done this. I'm not
sure what a UI would usefully do with this information, but it's there.

Another potential pitfall is highlighted by the proto-XEP: suppose Tybalt
has two resources, /library (dnd, 'researching') and /garden
(xa, 'gone to the library'). If Juliet tries to call Tybalt and sends a
successful decloak request, Tybalt's two resources will reply in an arbitrary
order, and Juliet will probbaly call whichever one answered first; even if she
waits for an arbitrary time, say 5 seconds, in the hope of getting more
replies, gets the second presence, *then* calls, she can't know which of
/garden and /library is "more available".

Any thoughts on this protocol?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100113/3d6efd81/attachment.sig>

More information about the Standards mailing list