Re: [Stox] core: connecting to remote domain

[Peter Saint-Andre <[e-mail]>]

On 6/21/13 12:49 AM, Adrian Georgescu wrote:
>>> Yes, this is a scenario where an operator provides a service
>>> using only one of the protocols (typically SIP) and only uses
>>> gateway for bridging traffic transparently to other XMPP domains
>>> without users having to know that the foreign user is using
>>> either SIP or XMPP. It is the SIP server that has the logic to
>>> make this routing decision and the gateway has a trusted
>>> relations ship with this server to avoid fraudulent usage of such
>>> service. The clients only talk to their respective native
>>> servers, not directly to the gateway. Same as clients do not talk
>>> directly to PSTN gateways, they rely on their servers to make
>>> such decisions.
>> 
>> Right, that makes sense.
>> 
>> I was thinking about the interdomain communication: if the SIP
>> user [e-mail] sends a message to [e-mail], he
>> doesn't need to know or care if Juliet uses SIP or XMPP, but the
>> service at example.org needs to determine how it will route the
>> message to Juliet (i.e., using SIP or XMPP). So it needs to
>> complete some kind of discovery or it needs to be configured to
>> "just know" that example.org is (say) a SIP service.
>> 
>> However, while completing a copy edit on the groupchat spec this
>> morning I noticed that we already have the following text:
>> 
>> Upon receiving the INVITE, the SIP-to-XMPP gateway needs to
>> determine the identity of the remote domain, which it does by
>> performing one or more DNS SRV lookups [RFC2782].  The SIP-to-XMPP
>> gateway SHOULD resolve the address present in the To header of the
>> INVITE to an im URI, then follow the rules in [RFC3861] regarding
>> the "_im" SRV service for the target domain contained in the To
>> header.  If SRV address resolution fails for the "_im" service, the
>> SIP-to-XMPP gateway MAY attempt a lookup for the "_xmpp-server"
>> service as specified in [RFC6120] or MAY return an error to the
>> sender (i.e. 502 Bad Gateway).
> 
> In practice we do lookup _xmmp_server, I  personally never saw a
> deployment of those _im records in the real world as of yet but
> others may confirm if this is the rule or the exception. Does anyone
> know a public service using those?

I deployed them at jabber.org, but we might be the only ones. :-)

>> Now, that text is probably old (we've been working on these
>> mapping specs for a long time) and thus probably predates the
>> updated XMPP RFCs. If we're not going to recommend use of the "_im"
>> and "_pres" SRV records, then connections to remote domains a
>> likely a matter for implementation and deployment.
> 
> It is a matter of implementation

Although I'd like to have something more automated, I think you're right.

>> However, I'd hate to do all this work on the mapping specs and then
>> leave the hard federation bits up to folks in the field who might
>> not be able to easily configure these services.
> 
> Nothing breaks if a gateway tries to lookup those records too, it is
> harmless yet useless as far as I can see because of lack of adoption.

Sadly, yes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/