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

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Jan 5 17:28:15 UTC 2010


Hi,
I'm trying to pick up some earlier work on making Jingle calls work for JIDs
to which the caller isn't subscribed. The use case I'm particularly interested
in is calling arbitrary SIP addresses via a Jingle-to-SIP gateway component
(telepathy-fargo, under development).

Previous discussions on XMPP lists[1] have several proposals. The most
concrete that I can find is that in December 2008, after discussion with Rob
McQueen, psa suggested a protocol he referred to as "decloaking" or "smoking
out" presence[2]:

> If you don't share presence, the smoke-out stuff would enable you to
> learn all this good information on an opt-in basis. So something like
> this (here I call it "decloak" instead of "smoke-out"):
> 
> <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 directed presence is then broadcast to all your resources, which
> then know that I want to decloak and share capabilities with you for the
> purpose of further communication.
> 
> If you approve, your client then also decloaks:
> 
> <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>
> 
> Now I know the capabilities of your "bar" resource, which we hope
> include support for Jingle. So I can send a Jingle invite from my "foo"
> resource to your "bar" resource and we can have a voice and video chat
> (or whatever).

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>

Has there been further discussion that I've missed while reading through the
archives?

The goal I'm trying to achieve is:

* xmpp:alice at example.com wants to call sip:12345 at example.org (perhaps she just
  typed 12345 into a dial-pad). She has previously registered on a gateway
  sip.example.com, so it will log in as sip:alice at example.org on her behalf.
* Alice sends some indication to 12345%example.org at sip.example.com that she
  would like it to respond with its presence, because she is about to call it
* 12345%example.org at sip.example.com sends back directed presence, containing
  only <presence><c .../></presence> (no <show>, avatar etc.)
* Alice now knows 12345's resource (or, more likely, she knows that this
  particular gateway should be called using a bare JID)
* Alice performs service discovery to interpret 12345's caps hash
* Alice now knows that the gateway JID can accept Jingle calls with certain
  dialects etc., and can call it

or more generally:

* XMPP users Alice and Bob have no subscription in either direction
* Alice wants to call Bob, perhaps by typing his JID into a UI, without
  necessarily setting up a subscription
* Alice sends some indication to Bob that she would like him to respond with
  presence so that he can be called
* Optionally, Alice includes her own presence/caps in that indication
* According to client configuration, Bob's client either ignores Alice,
  sends back directed presence containing only <presence><c .../></presence>
  (no <show>, avatar etc.), or asks Bob what to do
* Alice now knows Bob's resource
* Alice performs service discovery to interpret Bob's caps hash
* Alice now knows that Bob can accept Jingle calls with certain
  dialects etc., and can call him
* Bob can optionally send Alice an unavailable presence after a reasonable time
  without receiving a call, or after the call ends; Alice can behave similarly

Potential pitfalls:

* 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...

Problems with the general case, which are, however, not a problem for the
gateway case:

* If we want to support calling unsubscribed GTalk users, then the temporary
  pseudo-subscription request needs to be a modified subscription request,
  which all existing clients will display like a genuine subscription request
  (OTOH, that's what you have to do anyway to be able to call anyone at the
  moment...); the business rules for a temporary pseudo-subscription request
  are unclear (should you accept it and revoke acceptance, or send directed
  presence and never actually subscribe them, or what?)

* 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

* If Bob wants to be prompted whether to allow this, he could see poor UI
  (potentially, one popup for "let Alice see you're online so she can call
  you?", followed by either another popup for accepting/rejecting the call,
  or nothing if Alice turns out not to have any dialects in common with Bob...)
  although this is not necessarily a problem with more elaborate UI design

Thoughts? I'm going to try writing this up as a pseudo-XEP and implementing it
in a telepathy-gabble branch.

Regards,
    Simon

[1] linked on http://telepathy.freedesktop.org/wiki/XMPP/Directed%20Presence
[2] http://mail.jabber.org/pipermail/jingle/2008-December/000309.html
[3] http://mail.jabber.org/pipermail/standards/2008-August/019511.html
-------------- 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/20100105/59b3ec3e/attachment.sig>


More information about the Standards mailing list