Re: [Stox] core issues

Saúl Ibarra Corretgé <saul@ag-projects.com> Wed, 21 August 2013 19:36 UTC

Return-Path: <saul@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 0DB7811E8124 for <stox@ietfa.amsl.com>; Wed, 21 Aug 2013 12:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.818
X-Spam-Level:
X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, 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 PC+swLwFwxKB for <stox@ietfa.amsl.com>; Wed, 21 Aug 2013 12:36:15 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id AF28C11E8113 for <stox@ietf.org>; Wed, 21 Aug 2013 12:36:10 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 6FA7A374001; Wed, 21 Aug 2013 21:36:09 +0200 (CEST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D9A24344001; Wed, 21 Aug 2013 21:35:52 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="iso-8859-1"
From: Saúl Ibarra Corretgé <saul@ag-projects.com>
In-Reply-To: <52150EF5.5060401@alum.mit.edu>
Date: Wed, 21 Aug 2013 21:35:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6EEBE80-183A-4921-A1CC-B7E52C9D9C24@ag-projects.com>
References: <E44893DD4E290745BB608EB23FDDB7620A07605C@008-AM1MPN1-042.mgdnok.nokia.com> <52125D9C.5080609@stpeter.im> <3816E434-747C-4E45-A713-393B4E1AAD01@edvina.net> <5213ED3D.2010709@stpeter.im> <5213F090.4000104@gmail.com> <521400CF.8020801@alum.mit.edu> <521469A0.80104@gmail.com> <52150EF5.5060401@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1085)
Cc: stox@ietf.org
Subject: Re: [Stox] core issues
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: Wed, 21 Aug 2013 19:36:21 -0000

On Aug 21, 2013, at 9:03 PM, Paul Kyzivat wrote:

> On 8/21/13 3:17 AM, Daniel-Constantin Mierla wrote:
>> 
>> On 8/21/13 1:50 AM, Paul Kyzivat wrote:
> 
>>> You can make it sound easy by ignoring the details, but at the expense
>>> of quality of implementation.
>>> 
>>> The problem is that you may get multiple early dialogs, with media. At
>>> that time you don't know which one will answer first. So what do you
>>> do with the media while awaiting a 2xx?
>>> 
>>> You can't "pick one" without the risk that it is the wrong one.
>>> 
>>> You can "pick one" and switch it if it turns out to be the wrong one.
>>> But unless you relay the media the xmpp side will see a change, and so
>>> there must be some plan for how that is handled.
>> My comments were for the remark related to multiple 200ok, I haven't
>> said sending BYE for additional early dialogs.
> 
> They are tightly connected issues.
> 
>> For multiple early dialogs, the gateway has to maintain all of them
>> until a 200ok. It's also implementation decision which of early media
>> streams is sent to xmpp/jingle (again, it looks like it's mostly the
>> first one from experiences out there).
> 
> This is straightforward if the GW terminates/relays media.
> But that is a cost.
> 
> A signaling-only GW can't easily or thoroughly prevent the multiple early media streams from reaching the xmpp client. (It may be able to send updates to all but one to stop their media, but that takes some time, and not all will support it.)
> 
> So either you mandate that the GW terminate the media, or else you have to acknowledge the situation and warn the xmpp client to be prepared.
> 

I see the subject hasn't changed, so are we talking about the -core draft or the -media draft here? The early media situation is indeed tricky when RTP is being used, but if we are dealing with chat, there should be no problem in keeping a few TCP connections alive until one of the dialogs has been confirmed. Also, when chat is in use the GW effectively terminates the media.

--
Saúl Ibarra Corretgé
AG Projects