Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/29/09 5:15 AM, Pedro Melo wrote:
Hi,
On 2009/09/29, at 11:20, Paul Witty wrote:
As a bit of background on what I'm trying to do, I'm implementing a
SIP to XMPP/Jingle gateway. The gateway is connected to the XMPP
server as a component (e.g. sipgw.xmppserver.com) and so the Jingle
client can make a call to [email protected], which then
routes this to sip://1.2.3.4. However, in the other direction, a SIP
call to sip://p...@sipgw can be routed by the SIP gateway to the JID
[email protected], but without presence information this is
insufficient to make a Jingle call.
The two solutions to this I can see is either for the SIP gateway to
have privileges which allow it access to presence information for
clients registered to its server through sending a presence probe for
any user (but which I assume is not supported), or to have the gateway
send a presence subscription request each time a call comes to a
previously uncalled user, and maintaining the roster, which is clunky
both on the gateway side and for the user experience.
Clients that want to use the SIP gateway must register with it using
XEP-0100. In the process, the service subscribes the user presence.
I think you really need the registration part, so that the SIP gateway
knows how to map p...@sipgw to p...@xmppserver.
Whether you use registration or a component with special privileges, I
think you'll need presence information to route correctly between SIP
and XMPP (e.g., you might need entity capabilities or disco info about
XMPP endpoints for certain use cases, as mapped out in some of the
SIP-XMPP interworking specs).
Absolutely: you need presence information to find which resources are
connected, and service discovery to find which can do Jingle. But I
don't want to be subscribed to the destination's presence and therefore
have to keep track of the changes in presence state; I just want to send
a probe to get their online resources at the point which I need them.
--
Paul
