Subject: [Stox] core: connecting to remote domain

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jun 2013 16:35:35 -0600

While working on the sip-xmpp-groupchat spec today, Saúl and I found
what I think is an open issue wiht the sip-xmpp-core spec: it doesn't
say how you determine whether a remote domain supports SIP or XMPP (or
both). This is needed for interdomain routing of messages. Thus I
think the sip-xmpp-core spec needs to contain something like the text
in Section 11.2 of RFC 3921:

###

11.2. Outbound Stanzas

   If the hostname of the domain identifier portion of the address
   contained in the 'to' attribute of an outbound stanza matches a
   hostname of the server itself, the server MUST deliver the stanza to
   a local entity according the rules for Inbound Stanzas (Section
   11.1).

   If the hostname of the domain identifier portion of the address
   contained in the 'to' attribute of an outbound stanza does not match
   a hostname of the server itself, the server MUST attempt to route the
   stanza to the foreign domain.  The recommended order of actions is as
   follows:

   1.  First attempt to resolve the foreign hostname using an [SRV]
       Service of "xmpp-server" and Proto of "tcp", resulting in
       resource records such as "_xmpp-server._tcp.example.com.", as
       specified in [XMPP-CORE].

   2.  If the "xmpp-server" address record resolution fails, attempt to
       resolve the "_im" or "_pres" [SRV] Service as specified in
       [IMP-SRV], using the "_im" Service for <message/> stanzas and the
       "_pres" Service for <presence/> stanzas (it is up to the
       implementation how to handle <iq/> stanzas).  This will result in
       one or more resolutions of the form "_im.<proto>.example.com." or
       "_pres.<proto>.example.com.", where "<proto>" would be a label
       registered in the Instant Messaging SRV Protocol Label registry
       or the Presence SRV Protocol Label registry: either "_xmpp" for
       an XMPP-aware domain or some other IANA-registered label (e.g.,
       "_simple") for a non-XMPP-aware domain.

   3.  If both SRV address record resolutions fail, attempt to perform a
       normal IPv4/IPv6 address record resolution to determine the IP
       address using the "xmpp-server" port of 5269 registered with the
       IANA, as specified in [XMPP-CORE].

   Administrators of server deployments are strongly encouraged to keep
   the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly
   synchronized, since different implementations might perform the "_im"
   and "_pres" lookups before the "xmpp-server" lookup.

###

However, we'd need text describing the discovery and decision process
in both directions (and IMHO we need to drop the _im and _pres SRV
stuff, as we did when working on RFC 6121).

Thoughts?

Peter

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 20 Jun 2013 08:22:54 +0200

Hi!

On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Well, the problem is that in practice a given domain would have records for both SIP and XMPP, so which one would we check first? I'm not sure if we can define an unequivocal mechanism to choose the right target, so I'm tempted to suggest not to define it for the moment and leave it as a local policy item. If we come up with a way to do it later on, maybe we can create a new document updating sip-xmpp core?

> stuff, as we did when working on RFC 6121).

I have never seen _im and _pres out in the wild, so I'm +1 on removing the mention to them.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 20 Jun 2013 08:28:48 +0200

XMPP has defined DNS records for both C2S and S2S connections. One domain may have a server to server XMPP capability but would not accept client connections (missing correspondent  DNS record), this would give me a clue that that foreign domain has such XMPP 2 SIP gateway in place and if I am a client of that domain I know I cannot use an XMPP client for it. For SIP however, is not clear as the same DNS records are used both by clients and servers to locate the Proxy/Registrar for a given domain. This is the missing piece that makes a heuristic approach not 100% accurate. 

Adrian

On Jun 20, 2013, at 8:22 AM, Saúl Ibarra Corretgé <[email-masked]> wrote:

> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 20 Jun 2013 08:40:57 +0200

> XMPP has defined DNS records for both C2S and S2S connections. One domain may have a server to server XMPP capability but would not accept client connections (missing correspondent  DNS record), th…

The absence of C2S records could give you a hint, but some gateways may actually implement it thus allowing you to be on both SIP and XMPP at the same time from the same domain, so you'll still be confronted with the same problem. Not to mention deployments where SIP and XMPP are deployed in parallel for the same domain, which I think it's quite common these days.

Earlier this year, at XMPP summit, someone mentioned that S-NAPTR could be used for this. Looks like it actually would. See http://tools.ietf.org/html/rfc3958#section-4.3

I have never seen that deployed though.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 20 Jun 2013 12:11:05 +0300

Hi,

On 6/20/13 9:22 AM, Saúl Ibarra Corretgé wrote:
> Well, the problem is that in practice a given domain would have records for both SIP and XMPP, so which one would we check first? I'm not sure if we can define an unequivocal mechanism to choose the right target, so I'm tempted to suggest not to define it for the moment and leave it as a local policy item.

if a domain has a record for both SIP and XMMP
then if you are an XMPP client, it seems normal to me try first the XMPP one
(and the other way around if I am a SIP UA)

or I am missing something here?

>   If we come up with a way to do it later on, maybe we can create a new document updating sip-xmpp core?
>
+1 on removing them

/Salvatore

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 20 Jun 2013 12:16:50 +0300

On 6/20/13 9:28 AM, Adrian Georgescu wrote:
> XMPP has defined DNS records for both C2S and S2S connections. One domain may have a server to server XMPP capability but would not accept client connections (missing correspondent  DNS record), this would give me a clue that that foreign domain has such XMPP 2 SIP gateway in place and if I am a client of that domain I know I cannot use an XMPP client for it.
sorry but what would be the reason to have (and expose thru DNS) an 
XMPP2SIP gateway and then not let it to be accessible from a client?
are you assuming that a XMPP2SIP gateway is always only an outbound one?

/Salvatore

> For SIP however, is not clear as the same DNS records are used both by clients and servers to locate the Proxy/Registrar for a given domain. This is the missing piece that makes a heuristic approach not 100% accurate.
>
> Adrian
>
>

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 10:37:02 +0000

Hi Sal,

Salvatore Loreto wrote:
> > XMPP has defined DNS records for both C2S and S2S connections. One
> > domain may have a server to server XMPP capability but would not accept
> > client connections (missing correspondent  DNS record), this would give me a
> > clue that that foreign domain has such XMPP 2 SIP gateway in place and if I
> > am a client of that domain I know I cannot use an XMPP client for it.
>

I suppose it would be the case where the domain only runs a SIP service internally, and just offers an XMPP gateway to external domains. So, if you have an XMPP-only client, you would have to get an account for some other domain to be able to communicate with this SIP-only domain.

Markus

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 20 Jun 2013 12:53:30 +0200

>> XMPP2SIP gateway and then not let it to be accessible from a client?

If the gateway can accept XMPP client connections, I see no problem. Is just that in my experience the XMPP client connections are handled by the native XMPP server of the XMPP domain and the gateway has limited functionality and will only be used for the translation to SIP and nothing else. Of course one can have a monolith server that handles everything but this does not change the topology of the call flow, there are still two different functions, handling the C2S connection and bridging outside to another server using a S2S connection.

>> are you assuming that a XMPP2SIP gateway is always only an outbound one?

It s used for both directions of course, I cannot see why would be used just in one direction.

> I suppose it would be the case where the domain only runs a SIP service internally, and just offers an XMPP gateway to external domains.

This is my scenario.

> So, if you have an XMPP-only client, you would have to get an account for some other domain to be able to communicate with this SIP-only domain.

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 Jun 2013 11:55:42 -0600

On 6/20/13 4:53 AM, Adrian Georgescu wrote:
>>>> XMPP has defined DNS records for both C2S and S2S connections.
>>>> One domain may have a server to server XMPP capability but
>>>> would not accept client connections (missing correspondent  DNS
>>>> record), this would give me a clue that that foreign domain has
>>>> such XMPP 2 SIP gateway in place and if I am a client of that
>>>> domain I know I cannot use an XMPP client for it.
>>> 
>>> sorry but what would be the reason to have (and expose thru DNS)
>>> an XMPP2SIP gateway and then not let it to be accessible from a
>>> client?
> 
> If the gateway can accept XMPP client connections, I see no problem.
> Is just that in my experience the XMPP client connections are handled
> by the native XMPP server of the XMPP domain and the gateway has
> limited functionality and will only be used for the translation to
> SIP and nothing else. Of course one can have a monolith server that
> handles everything but this does not change the topology of the call
> flow, there are still two different functions, handling the C2S
> connection and bridging outside to another server using a S2S
> connection.
> 
>> I suppose it would be the case where the domain only runs a SIP
>> service internally, and just offers an XMPP gateway to external
>> domains.
> 
> This is my scenario.
> 
>> So, if you have an XMPP-only client, you would have to get an
>> account for some other domain to be able to communicate with this
>> SIP-only domain.
> 
> 
> 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
[email-masked] sends a message to [email-masked], 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).

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

Peter

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

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 21 Jun 2013 08:49:12 +0200

>   specified in [RFC6120] or MAY return an error to the sender (i.e. 502

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?

> implementation and deployment.

It is a matter of implementation

> However, I'd hate to do all this work on

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Jun 2013 06:32:02 -0600

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 [email-masked] sends a message to [email-masked], 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.
> 

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/