I agree that addressing should be simplified. For foreign domains is is
easy, decision should be DNS based. For same domain, i consider that is
more a mater of the platform design. There could be a flag per user to
specify if the user has SIP or XMPP account. I see no obvious reason to
have both, once there will be full gatewaying capabilities. The logic
should check if the user is registered with the server that got the
message, and if not, forward to the gateway. From SIP side, this can be
easily achieved with openser, I have no idea about jabber side, if you
can have some custom routing rules.
Cheers,
Daniel
On 10/05/06 16:03, Juha Heinanen wrote:
i read xmpp module documentation. i think i understood it except for
one thing. it says:
You can run an instance of OpenSER on a separate machine or on different
port with the following config, and have the main SIP server configured
to forward all SIP requests for XMPP world to it.
the question is, how do i know which messages i should sent to xmpp
world?
ideally, a user should be able to use both sip and xmpp clients. at
minimum, it should be possible in the same domain to use both clients.
so i cannot tell based on host part or r-uri if the uri belongs to an
xmpp client or a sip client.
looks like the current solution is two way two level addressing:
sip:username<delim>[EMAIL PROTECTED]
sip_username<delim>[EMAIL PROTECTED]
this is fine for testing purposes, but in longer run we should be able
to get rid of two levels.
if r-uri host of sip request is local, sip proxy could fork the request
to sip client(s) and sip-xmpp gw assuming an external xmpp server
is used. i don't know if forking could also be done the other way in
external xmpp server so that request from xmpp world could be sent to
both xmpp client(s) and through gateway to sip clients.
support for both sip and xmpp clients in local domains would be easier
if sip im/presence server could be integrated with xmpp server. i don't
know how big development effort that would be. jabberd2 is written in
c, so perhaps most of the code could be re-used. then the integrated
server would be able to support both sip and xmpp clients using the same
user database. with radius, the latter is easy already now without any
new code.
if r-uri of sip request belongs to foreign domain, then we would need to
make some dns SRV queries to figure out if the foreign domain supports
sip and/or xmpp. if both, it should be possible to send the request to
the foreign server using the same protocol it came in to local sip
proxy/xmpp server.
comments?
-- juha
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
