Re: [Stox] core issues

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 21 August 2013 19:03 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 2691711E810A for <stox@ietfa.amsl.com>; Wed, 21 Aug 2013 12:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level:
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=-0.344, 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 wPX8LqBL47dE for <stox@ietfa.amsl.com>; Wed, 21 Aug 2013 12:03:19 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 061D121F9F2D for <stox@ietf.org>; Wed, 21 Aug 2013 12:03:18 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id FPQt1m00417dt5G54X3J1t; Wed, 21 Aug 2013 19:03:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id FX3J1m00H3ZTu2S3ZX3J9N; Wed, 21 Aug 2013 19:03:18 +0000
Message-ID: <52150EF5.5060401@alum.mit.edu>
Date: Wed, 21 Aug 2013 15:03:17 -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>
In-Reply-To: <521469A0.80104@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377111798; bh=ibX148IxXzXAwjEvrCLOCOt0uXEh2EETGVGHgGMxWeY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qO3zP/LRMRZ8LQiz+va455U4WieEgU3mZUVKnf6enyfUbsR8kMvimRy2+iwF7fAfX Ute7kEHUxWYuuBwCIOo867ZFYsLB0EjlNrqDaMmXG/3Oy/RJs5SPWPEMdX+qQDCVtE XpyQmQ764btqowbaA3YXZofn9q2JSy8hs9YUQ7HUjKiE++1cQsTpSPWthtRqx3z8dF zP0yBJKD8ekmYt8rb4GGBWsBzwYZESzUoxUPrfks7LdxKPFn3gExVcmHqQ2gK4fX2C 5Ob3//+kTScieHmzJjWipTCqyKFkIIM/aLMUHJ9zOKaW8AfNK2yPZEC535fnXj+Rp1 ZWIhfD9pxR2ww==
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:03:32 -0000

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.

	Thanks,
	Paul