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:[email protected] wants to call sip:[email protected] (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:[email protected] on her behalf. * Alice sends some indication to 12345%[email protected] that she would like it to respond with its presence, because she is about to call it * 12345%[email protected] 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
signature.asc
Description: Digital signature
