Re: [Stox] core: connecting to remote domain

Peter Saint-Andre <stpeter@stpeter.im> Thu, 20 June 2013 17:55 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D008C21F8263 for <stox@ietfa.amsl.com>; Thu, 20 Jun 2013 10:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.164
X-Spam-Level:
X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7LttWBzzLJp for <stox@ietfa.amsl.com>; Thu, 20 Jun 2013 10:55:46 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF8821F9EC3 for <stox@ietf.org>; Thu, 20 Jun 2013 10:55:46 -0700 (PDT)
Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6B3C412C9; Thu, 20 Jun 2013 11:55:46 -0600 (MDT)
Message-ID: <51C3421E.8020808@stpeter.im>
Date: Thu, 20 Jun 2013 11:55:42 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Adrian Georgescu <ag@ag-projects.com>
References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> <B66E77A7-ADB3-48F4-B359-8839D6EAAD64@ag-projects.com> <51C2C882.5050107@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620A01DB9D@008-AM1MPN1-042.mgdnok.nokia.com> <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com>
In-Reply-To: <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: salvatore.loreto@ericsson.com, stox@ietf.org, Markus.Isomaki@nokia.com
Subject: Re: [Stox] core: connecting to remote domain
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 17:55:58 -0000

On 6/20/13 4:53 AM, Adrian Georgescu wrote:
> 
> On Jun 20, 2013, at 12:37 PM, <Markus.Isomaki@nokia.com> wrote:
> 
>> Hi Sal,
>> 
>> Salvatore Loreto wrote:
>>> 
>>> 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?
> 
> 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.

Right, that makes sense.

I was thinking about the interdomain communication: if the SIP user
romeo@example.com sends a message to juliet@example.org, 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/