Subject: [Stox] sip-xmpp-core: gateway in source or destination domain?

From: <[email-masked]>
Date: Tue, 4 Jun 2013 10:46:44 +0000

Hi,

The sip-xmpp-core draft [1] says:

 "We further assume that protocol translation
   will occur within a gateway in the source domain, so that information
   generated by the user of an XMPP service will be translated by a
   gateway within the trust domain of that XMPP service, and information
   generated by the user of a SIP service will be translated by a
   gateway within the trust domain of that SIP service."

In the context of STOX, I have a few questions about this:
- Is this how the current deployments in general work? Is that enough?
- Should we keep this assumption or also explicitly consider the case where the gateway would be in the destination domain?
- If we wanted to take destination-domain gateways into consideration, what would the implications be to the mapping specs? 

Regards,
	Markus 

[1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 4 Jun 2013 14:29:35 +0200

> - Is this how the current deployments in general work? Is that enough?

I deployed this service and and this is how it works.  It is enough in my experience and doe snot require any new addressing scheme or location service. 

> - Should we keep this assumption or also explicitly consider the case where the gateway would be in the destination domain?

Not sure how one could know what gateways the foreign domain has and for what purpose. One can only lookup DNS records for specific services like SIP or XMPP. You do not know if they are gateways or something else. The local domain policy can detect a remote domain capability and route based its own policy.

> - If we wanted to take destination-domain gateways into consideration, what would the implications be to the mapping specs? 

One can only decide what to do for its own domain and advertise it into the DNS. One cannot guess or know about topology of a foreign domain, can't he?

Adrian

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

---

From: <[email-masked]>
Date: Tue, 4 Jun 2013 13:25:22 +0000

Hi Adrian,

Thanks. One clarification about your deployment:

> I deployed this service and and this is how it works.  It is enough in my experience and doe snot require any new addressing scheme or location service.

So, when one domain runs SIP and the other domain runs XMPP, in order to talk to each other, each domain is responsible for deploying a gateway that translates outgoing messages from their "native" protocol to the other protocol? It is not enough to just deploy a gateway in one of the domains (and have that domain advertise both SIP and XMPP in DNS)?

Current "sip-xmpp-core" draft explicitly assumes that SIP messages are translated to XMPP in the SIP domain, while XMPP messages are translated to SIP in the XMPP domain. 

What I was wondering is how that assumption in practice affects the draft-saintandre-sip-xmpp-* specs in general. To my understanding the mappings are the same no matter in which trust domain the gateway is located. The sip-xmpp-core does talk about the DNS operations which are certainly affected depending on where the translation happens. 

Markus 

-----Original Message-----
From: ext Adrian Georgescu [mailto:[email-masked]] 
Sent: 04 June, 2013 15:30
To: Isomaki Markus (Nokia-CIC/Espoo)
Cc: [email-masked]
Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain?

Adrian

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 4 Jun 2013 15:36:06 +0200

> Current "sip-xmpp-core" draft explicitly assumes that SIP messages are translated to XMPP in the SIP domain, while XMPP messages are translated to SIP in the XMPP domain. 

This is most likely not possible in real life because it would require that both domains have such gateway in place and in practice the chance of this happening is close to zero (unless adoption of such solution goes through the roof, unlikely). Most likely the SIP/XMPP gateway is deployed only by those who care about such interoperability, the remote domains may not care and they should not know or be required to do anything about this, it should just work.

My use case is the following. 

I serve SIP users and I want to provide my users with the possibility to interact with remote XMPP domains without having to know or configure anything in their SIP clients. For this purpose, I have configured my SIP server to route outgoing requests for that XMPP remote domain through the gateway I control. For receiving incoming requests from any remote XMPP domains, I configured the proper XMPP related  DNS records to point to the same gateway (its XMPP server listening interface). This was it works both ways and the remote XMPP domain does not need to have a gateway not does he  need to know anything about my topology or the fact that I have a gateway, it just talks native XMPP as it would federate with any other XMPP foreign domain.

> What I was wondering is how that assumption in practice affects the draft-saintandre-sip-xmpp-* specs in general. To my understanding the mappings are the same no matter in which trust domain the g…

Again, requiring both domains to have such gateway is both unnecessary and unrealistic. Nobody can be forced to deploy a gateway just because a foreign domain would lkike or require so. If the remote domain cares about talking my protocol, they should deploy a gateway on their own and it should just talk to my service natively.

Adrian

---

From: <[email-masked]>
Date: Tue, 4 Jun 2013 14:41:05 +0000

Hi Adrian,

I agree with everything you say below, and that has also been my assumption of how the deployments will work.

I'm probably just reading the sip-xmpp-core too literally. If so, it would be useful in the next update of that document to make it a bit clearer.  

Markus 

-----Original Message-----
From: ext Adrian Georgescu [mailto:[email-masked]] 
Sent: 04 June, 2013 16:36
To: Isomaki Markus (Nokia-CIC/Espoo)
Cc: [email-masked]
Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain?

Adrian

>> "We further assume that protocol translation  will occur within a 
>> gateway in the source domain, so that information  generated by the 
>> user of an XMPP service will be translated by a  gateway within the 
>> trust domain of that XMPP service, and information  generated by the 
>> user of a SIP service will be translated by a  gateway within the 
>> trust domain of that SIP service."
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Jun 2013 09:02:49 -0600

On 6/4/13 6:29 AM, Adrian Georgescu wrote:
>> In the context of STOX, I have a few questions about this: - Is
>> this how the current deployments in general work? Is that enough?
> 
> I deployed this service and and this is how it works.  It is enough
> in my experience and doe snot require any new addressing scheme or
> location service.
> 
>> - Should we keep this assumption or also explicitly consider the
>> case where the gateway would be in the destination domain?
> 
> Not sure how one could know what gateways the foreign domain has and
> for what purpose. One can only lookup DNS records for specific
> services like SIP or XMPP. You do not know if they are gateways or
> something else. The local domain policy can detect a remote domain
> capability and route based its own policy.

Agreed. Some services / products have implemented destination-side
gateways, also called connection managers. A client or peer server would
connect via its preferred protocol (say, SIP) because the service
advertised support for it, but the service would translate the SIP
traffic into XMPP at the connection manager and natively operate using
XMPP within the other parts / core of the service. A similar approach
could be taken for a SIP-based system (offer an XMPP connection manager)
or for a system that uses some other / proprietary protocol internally
(in which case the service might have connection managers for both SIP
and XMPP). But those details are service-specific and I agree with
Adrian that we really can't say much about those internals, if anything.

>> - If we wanted to take destination-domain gateways into
>> consideration, what would the implications be to the mapping specs?
>> 
> 
> One can only decide what to do for its own domain and advertise it
> into the DNS. One cannot guess or know about topology of a foreign
> domain, can't he?

No. But I don't think we need to limit the mappings to source-side
translation -- that was just a simplifying assumption we made for the
sake of the examples, not an architectural recommendation. So that's
something we need to make clearer in the core spec.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Jun 2013 09:08:45 -0600

> something we need to make clearer in the core spec.

Here is proposed text.

OLD
   This document assumes that a gateway will translate directly from one
   protocol to the other.  We further assume that protocol translation
   will occur within a gateway in the source domain, so that information
   generated by the user of an XMPP service will be translated by a
   gateway within the trust domain of that XMPP service, and information
   generated by the user of a SIP service will be translated by a
   gateway within the trust domain of that SIP service.

NEW
   This document assumes that a gateway will translate directly from one
   protocol to the other.  For the sake of the examples, we further
   assume that protocol translation will occur within a gateway in the
   source domain, so that information generated by the user of an XMPP
   service will be translated by a gateway within the trust domain of
   that XMPP service, and information generated by the user of a SIP
   service will be translated by a gateway within the trust domain of
   that SIP service.  However, nothing in this document ought to be
   taken as recommending against protocol translation at the destination
   domain.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Jun 2013 10:38:50 -0600

On 6/4/13 7:25 AM, [email-masked] wrote:

> Current "sip-xmpp-core" draft explicitly assumes that SIP messages
> are translated to XMPP in the SIP domain, while XMPP messages are
> translated to SIP in the XMPP domain.

Poorly phrased text. Please see my proposed fix.

Peter

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 14 Jun 2013 09:32:48 +0200

>   taken as recommending against protocol translation at the destination

+1.

--
Saúl Ibarra Corretgé
AG Projects