Re: [Stox] core issues

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 22 August 2013 20:41 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 A5FD611E81EB for <stox@ietfa.amsl.com>; Thu, 22 Aug 2013 13:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.121
X-Spam-Level:
X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 YHkzq5jgccKo for <stox@ietfa.amsl.com>; Thu, 22 Aug 2013 13:41:01 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id B117811E8135 for <stox@ietf.org>; Thu, 22 Aug 2013 13:41:01 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id Fnac1m0051HzFnQ56wh1mn; Thu, 22 Aug 2013 20:41:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id Fwh01m01C3ZTu2S3awh03x; Thu, 22 Aug 2013 20:41:01 +0000
Message-ID: <5216775B.6080709@alum.mit.edu>
Date: Thu, 22 Aug 2013 16:40:59 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: stox@ietf.org
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> <D6EEBE80-183A-4921-A1CC-B7E52C9D9C24@ag-projects.com>
In-Reply-To: <D6EEBE80-183A-4921-A1CC-B7E52C9D9C24@ag-projects.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377204061; bh=9aFwYBTkTxC9jh/heA3P0+cqsGwZLWzptZHP5G7Wx/M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XPoAix67ATLeGP0iUgZohlHF7TrW7Rp8EZ79gcmW+kgARralIGH7u9JTWAajVO2T6 73UvwtjL6cBAXQ9b0O2VMbwyLragG3H0RBHrH3Izn2ky/dUcxjdCe0iOrItoZlFyED IpdqFA3ZHsCRzhvxq1clDFNoxvZzY3T2AcsPu1umnyYPND9a9+HYC0oKehH8zcmPU+ MbMJTDG8iPgklpfTc6xs3Y9zkm2x0ShzFbdYBZpOqnn1Z5nl7kRfCRuojMRsJTdHUF Euw5FD1Ecfu0y5UC7J71+VjDdbKsSZOQD3IRNLaYeniY/3GHpTSm74BR1/EnBTjUBh cuQQVoKhioWDw==
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: Thu, 22 Aug 2013 20:41:07 -0000

On 8/21/13 3:35 PM, Saúl Ibarra Corretgé wrote:
>
> 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.

There isn't any way to have a signaling only GW for xmpp-msrp.
So yes, you are right about that. Its only an issue for RTP media.

	Thanks,
	Paul