Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 09 August 2013 18:33 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 5861D11E81D4 for <stox@ietfa.amsl.com>; Fri, 9 Aug 2013 11:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.282
X-Spam-Level:
X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, 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 l7TrI4vH-j-q for <stox@ietfa.amsl.com>; Fri, 9 Aug 2013 11:33:44 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2F21F8E8E for <stox@ietf.org>; Fri, 9 Aug 2013 11:28:00 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id Ab541m0031ZXKqc58iTuuT; Fri, 09 Aug 2013 18:27:54 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id AiTu1m00C3ZTu2S3hiTuoy; Fri, 09 Aug 2013 18:27:54 +0000
Message-ID: <520534A9.9050100@alum.mit.edu>
Date: Fri, 09 Aug 2013 20:27:53 +0200
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: Saúl Ibarra Corretgé <saul@ag-projects.com>
References: <7594FB04B1934943A5C02806D1A2204B1C418E51@ESESSMB209.ericsson.se> <8C703C0F-181C-4E36-8A59-727B45C0A1B5@ag-projects.com> <7594FB04B1934943A5C02806D1A2204B1C418FAC@ESESSMB209.ericsson.se> <B7CBEFB1-2A23-4337-90DD-D8157123A1AD@ag-projects.com> <7594FB04B1934943A5C02806D1A2204B1C41C17E@ESESSMB209.ericsson.se> <6E2B9398-C9C5-47F1-AC5D-2C7E23AB6E69@ag-projects.com> <7594FB04B1934943A5C02806D1A2204B1C41C208@ESESSMB209.ericsson.se> <51FEA128.2060806@ag-projects.com> <52011FEA.5040104@alum.mit.edu> <6A3963CE-AD8C-4C93-9E39-9268BA82AF4B@ag-projects.com>
In-Reply-To: <6A3963CE-AD8C-4C93-9E39-9268BA82AF4B@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=1376072874; bh=UaX+b4Zkeaglf2V+A7DpmHa8pc4U2kUChNuTEUQM/Hs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DP8PRYGmZnm/KMy84Ul2TaVMH2qHlZjCBIV7LOD9wh1xCSPztUhcDgwoyZEGersS6 OkBIGik6pFdiSrCFAME43IFlGzDiB7ytkUskTJpkAdz6N6bOi5imdmlAJNRxKQ4ytq wrkNM9NUCZCd9dWlXJVDA0lbtgDTPiC80hJNPKXl/Vu4iG6+iriD0M4cRH4nWGU9CI gizEgTtQlINiU0ojUX9bBleVLPFna9TepshC1AC7VvR9lwIAhDT3ovWBeR0JuauSae V6tzvBGgx1PHRYfoC0xEZf0UFnnc/MZZeH7pFhKjwKtzInunTBXNOGzN/HmTlz7prE NX5196hL7vzMQ==
Cc: stox@ietf.org
Subject: Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
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: Fri, 09 Aug 2013 18:33:50 -0000

On 8/8/13 12:18 AM, Saúl Ibarra Corretgé wrote:
>
> On Aug 6, 2013, at 6:10 PM, Paul Kyzivat wrote:
>
>> On 8/4/13 8:44 PM, Adrian Georgescu wrote:
>>> The gateway would care to translate the final response. Getting more
>>> then one 180 is not causing any harm nor does those need to be
>>> translated into different events on XMPP side.
>>
>> I think Christer's point is that the behavior you are describing needs to be described somewhere.
>>
>
> Indeed.
>
>> The typical issue is that forking results in multiple early dialogs. More than one may result in early media. To give good results the GW needs to pass on some or all of that early media to the XMPP side. If more than one has early media, then its difficult to know what to do. You might pass *one* of them on to the XMPP side.
>>
>
> I don't think we can pass the early media, since there is no way to do it today. I'd go for leaving it unspecified. There seems to be some action going on for rebooting Jingle, so when Jingle has a story for early media a new document could be written specifying it. Would this work for you? I know it doesn't cover all those mutli-edarly-dialog cases, but I'm not sure we can do nay better at this point.

This is a hard conversation to have, since I am almost totally ignorant 
of Jingle.

But I think what happens here must depend a bit on the nature of the GW. 
If it terminates media, then it can swallow the early media. But if it 
is only a signaling GW, and doesn't terminate the media, then it will 
only be negotiating using the SDP addresses of the SIP and Jingle 
endpoints. In that case its hard to avoid the early media. But it all 
depends on the sort of signaling you can do in the GW.

	Thanks,
	Paul

>> Most times *one* of those early dialogs will return a 200, and the others will be cancelled (by the gateway). But the one that returns the 200 may not be the one you were processing early media from. So there may need to be a media change.
>>
>
> Not if we don't translate early media ;-)
>
>> It is also possible that more than one of those early dialogs will return a 200. Then *something* needs to be done with all of those. The simplest is to hang up on one of them, though its also possible to conference them. So the GW needs to deal with this possibility, even though it will be rare.
>>
>
> Yeah, I think we could add some text about it, though what to do will be implementation specific, right?
>
>> You can *hope* that some sip server downstream of the GW will handle all of this and present the GW with a call flow that has no forking. But you can't count on this. There is nothing the GW can do to guarantee that will happen.
>>
>
> Right.
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>