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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 06 August 2013 16:10 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 B688D21F9E26 for <stox@ietfa.amsl.com>; Tue, 6 Aug 2013 09:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.098
X-Spam-Level:
X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[AWL=-0.335, 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 QEDLrD91Y7pC for <stox@ietfa.amsl.com>; Tue, 6 Aug 2013 09:10:39 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 609AB21F9ECA for <stox@ietf.org>; Tue, 6 Aug 2013 09:10:21 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id 9R8D1m0051wpRvQ59UALsT; Tue, 06 Aug 2013 16:10:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 9UAL1m0013ZTu2S3eUALgk; Tue, 06 Aug 2013 16:10:20 +0000
Message-ID: <52011FEA.5040104@alum.mit.edu>
Date: Tue, 06 Aug 2013 18:10:18 +0200
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: stox@ietf.org
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>
In-Reply-To: <51FEA128.2060806@ag-projects.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375805420; bh=W63s0ALWCLohxvVbQyGtcAD1dIiN/5B0cb3fk/dLzxo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hG1q89Era0BGFqME9+DDVq5l3kOl/DhU0Cz6rvbBTpBHRGoBRM5WnLu6Bc7x4wAjs 6hLzGdaOO/OKLHH8s/9houbn5trFXqj8c9OsGOvsvJQQT2JVnGW/nizFJS6L0RSzoE g8cPnE1Z/Q6+rNJWgwNaHoz+T3Je+bkWmnW5zUtDLS3Pfy6M6I0tdraMc/ajP2XxMO i/zp3T2ownEgtAtAm9xZucyRCkAhASVKj3b06rMU8sGKLPFDIBZPMRNEXX9Y+AwlrU aZO2TlKf16stzwjHxY48HqcBAH8BGEUO004694Lr4Hk+V32z8RcNzuVfTVYKVxb84r U/YDksMn0k83A==
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: Tue, 06 Aug 2013 16:10:44 -0000

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.

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.

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.

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.

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.

	Thanks,
	Paul

> Adrian
>
> On 08/04/2013 08:39 PM, Christer Holmberg wrote:
>>
>> Hi,
>>
>> I am not sure I understand.
>>
>> The server may implement SIP functions like forking, and fork the
>> INVITE. BUT, the gateway will still get the 18x responses for the
>> early dialogs – just like a SIP phone.
>>
>> Regards,
>>
>> Christer
>>
>> *Lähettäjä:*Adrian Georgescu [mailto:ag@ag-projects.com]
>> *Lähetetty:* 4. elokuuta 2013 20:20
>> *Vastaanottaja:* Christer Holmberg
>> *Kopio:* stox@ietf.org
>> *Aihe:* Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
>>
>> The gateway lookups the SIP server for a given domain in the DNS same
>> as any other device would do like a SIP phone configured with
>> credentials under that domain. Is the job of that server to properly
>> implement all SIP functions like forking proxy, handle nat traversal
>> or registrar to name a few common features.
>>
>> You ask what shall the world do if the SIP server of given domain does
>> not implemented forking or other feature. My answer is the gateway
>> must not care, is the problem of whomever manages that domain and its
>> applications to handle such features.
>>
>> Regards,
>>
>> Adrian
>>
>> On Aug 4, 2013, at 6:55 PM, Christer Holmberg wrote:
>>
>>
>>
>> Hi,
>>
>> There for sure may be a SIP server (a proxy, B2BUA and/or the remote
>> UAS) in the network, but how can you guarantee that it will handle
>> forking? A forking proxy will simply forward 18x responses forming the
>> early dialogs towards the gateway, which then will have to handle them.
>>
>> Regards,
>>
>> Christer
>>
>> *Lähettäjä:*Adrian Georgescu [mailto:ag@ag-projects.com]
>> *Lähetetty:*2. elokuuta 2013 13:36
>> *Vastaanottaja:*Christer Holmberg
>> *Kopio:*stox@ietf.org <mailto:stox@ietf.org>
>> *Aihe:*Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
>>
>> On Aug 2, 2013, at 12:30 PM, Christer Holmberg
>> <christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>> wrote:
>>
>>
>>
>>
>> Hi Adrian,
>>
>> >I would suggest that best practice is for the SIP traffic to be routed
>> to the SIP Proxy/Registrar/Presence Agent of the given domain behind
>> the gateway.That element has more proper capabilities for handling
>> forking or any other SIP features.
>>
>> Ok, but how are you going to ensure that such element exists?
>>
>> The gateway knows, it queries the DNS for the domain SIP service
>> records. If no proper records exist, the call flow will stop as there
>> is nothing to rote the calls flows to.
>>
>> Such gateway, its very existence, implies that there is both a SIP
>> Server and and XMPP server for each domain. It is a cross protocol
>> federation, the domain must exists otherwise there is nothing to
>> gateway to and there is no reason to deploy it.
>>
>> Adrian
>>
>>     Regards,
>>
>>     Christer
>>
>>     Otherwise you will move all SIP functionality into the XMPP
>>     gateway and must document that whole SIP universe as running
>>     inside that gateway, which makes little sense.
>>
>>     Regards,
>>
>>     Adrian
>>
>>     On Aug 2, 2013, at 12:16 PM, Christer Holmberg
>>     <christer.holmberg@ericsson.com
>>     <mailto:christer.holmberg@ericsson.com>> wrote:
>>
>>
>>
>>
>>
>>     Hi,
>>
>>     As I indicated at the STOX session (and was later repeated by
>>     Jonathan Lennox), the draft need to have a story on SIP forking,
>>     e.g. if what happens if the INVITE sent from the interworking node
>>     gets forked, and multiple early dialogs are created.
>>
>>     Regards,
>>
>>     Christer
>>
>>     _______________________________________________
>>     stox mailing list
>>     stox@ietf.org <mailto:stox@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/stox
>>
>>     _______________________________________________
>>     stox mailing list
>>     stox@ietf.org <mailto:stox@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/stox
>>
>> _______________________________________________
>> stox mailing list
>> stox@ietf.org <mailto:stox@ietf.org>
>> https://www.ietf.org/mailman/listinfo/stox
>>
>
>
>
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
>