IETF Logo Mail Archive

Re: [Stox] core issues

Daniel-Constantin Mierla <miconda@gmail.com> Wed, 21 August 2013 07:17 UTC

Return-Path: <miconda@gmail.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 98A5D21F9C76 for <stox@ietfa.amsl.com>; Wed, 21 Aug 2013 00:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level:
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 XxzV972GV1-7 for <stox@ietfa.amsl.com>; Wed, 21 Aug 2013 00:17:57 -0700 (PDT)
Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9316911E81D7 for <stox@ietf.org>; Wed, 21 Aug 2013 00:17:56 -0700 (PDT)
Received: by mail-ee0-f43.google.com with SMTP id e52so31050eek.30 for <stox@ietf.org>; Wed, 21 Aug 2013 00:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U9Ign+t+y7s9WtRKN2fsntU3WBfmASrr7SSMxCFm6L4=; b=PswCLrc4oFo6OXQScKRa9V9FA/995+cxILN75rLoxmNWHR37/6rRab+hGV+kqaZkdt n0eqo32ZCje/UfFVgZjtPyyA4hODDlY3/elRh0pUdhJNdp6q1ZK6Jlf0yCtdwrGehu9I KCZ2gxZ111WqeKF8NCP4TS73HF7eEnCsT00OpmC2GN+40gYCbtGxvCXvbpHZwhiOvDul 7Y7cLb6NhaBR3xH7TTVFm2Zdq5ZdxiDr1b0ENBBuQ9nv2YHREXTJsArhP5NEA8jwiiI2 /w0tbyDiOaCSi0KJkijgOGorN6rByH9Jg155dWy5ber6LugrOyCJwUu5l4iy4g2r7QsW iMhQ==
X-Received: by 10.14.37.4 with SMTP id x4mr8283740eea.16.1377069475659; Wed, 21 Aug 2013 00:17:55 -0700 (PDT)
Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id i1sm7465603eeg.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Aug 2013 00:17:54 -0700 (PDT)
Message-ID: <521469A0.80104@gmail.com>
Date: Wed, 21 Aug 2013 09:17:52 +0200
From: Daniel-Constantin Mierla <miconda@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
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>
In-Reply-To: <521400CF.8020801@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] core issues
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: miconda@gmail.com
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 07:17:57 -0000

On 8/21/13 1:50 AM, Paul Kyzivat wrote:
> On 8/20/13 6:41 PM, Daniel-Constantin Mierla wrote:
>>
>> On 8/21/13 12:27 AM, Peter Saint-Andre wrote:
>>> On 8/20/13 12:32 AM, Olle E. Johansson wrote:
>>>> 19 aug 2013 kl. 20:02 skrev Peter Saint-Andre <stpeter@stpeter.im>:
>>>>
>>>>> On 8/14/13 1:19 PM, Markus.Isomaki@nokia.com wrote:
>>>>>
>>>>>> * Core
>>>>>>
>>>>>> - Issue: Should something general about forking be defined here
>>>>>> or is it purely a -media issue?
>>>>> I think this is best left for the stox-media spec.
>>>> Do remember to handle the case where one sip INVITE can get multiple
>>>> 200 OK. It's a corner case, but it does happen. And it's signalling.
>>> That sounds like fun.
>> This should be caught by the gateway, handled locally, like any SIP
>> endpoint UA (and how is happening for PSTN gateways). Only one 200ok
>> should be propagated to xmpp/jingle side. Which one? A matter of the
>> implementation, most I have seen they go with the first response
>> received, for the others they send ACK followed quickly by BYE (I mean,
>> the good SIP UA implementations, some just crash in such cases :-) ).
>> Daniel
>
> 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.

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).

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

v2.23.0 | Report a Bug | By Email