Re: [Stox] core: connecting to remote domain

Adrian Georgescu <ag@ag-projects.com> Thu, 20 June 2013 10:53 UTC

Return-Path: <ag@ag-projects.com>
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 A8A9421F9B84 for <stox@ietfa.amsl.com>; Thu, 20 Jun 2013 03:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Level:
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_MLH_Stock1=0.87]
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 zOWbT78F3vpr for <stox@ietfa.amsl.com>; Thu, 20 Jun 2013 03:53:34 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BA1C821F9B80 for <stox@ietf.org>; Thu, 20 Jun 2013 03:53:33 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 33226B35DC; Thu, 20 Jun 2013 12:53:31 +0200 (CEST)
Received: from ag-retina.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 53C63B017C; Thu, 20 Jun 2013 12:53:31 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Adrian Georgescu <ag@ag-projects.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A01DB9D@008-AM1MPN1-042.mgdnok.nokia.com>
Date: Thu, 20 Jun 2013 12:53:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@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>
To: Markus.Isomaki@nokia.com
X-Mailer: Apple Mail (2.1508)
Cc: salvatore.loreto@ericsson.com, stox@ietf.org
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 10:53:38 -0000

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.
 


> 
> Markus
> 
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>