IETF Logo Mail Archive

Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 02 April 2014 21:49 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12F71A03D9 for <mmusic@ietfa.amsl.com>; Wed, 2 Apr 2014 14:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CHI0b-S6f5S for <mmusic@ietfa.amsl.com>; Wed, 2 Apr 2014 14:49:01 -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 3AEB01A03EC for <mmusic@ietf.org>; Wed, 2 Apr 2014 14:49:01 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id l0XR1n0050bG4ec599oxnK; Wed, 02 Apr 2014 21:48:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:f1cd:ca9a:c851:433e]) by omta03.westchester.pa.mail.comcast.net with comcast id l9nv1n0121vrKXX3P9nwQU; Wed, 02 Apr 2014 21:48:57 +0000
Message-ID: <533C8575.8030802@alum.mit.edu>
Date: Wed, 02 Apr 2014 17:47:33 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@ESESSMB209.ericsson.se>
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=q20140121; t=1396475337; bh=W4bz8kpbmruAROdEl5ZLLifyvnwLBBsnNvKicgpwOWU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AjwpFidMcXDlCVIfzYESEV7o1etjptUHr5RurK8C/v5b+qlUud873pI+P+kwWJLzp lzK68R0k1/Ys+rGeV8A/0RAs1ucvh69UPCD7EI6Q3CZ3tINTzfDSkooZJp9gIB+Ydv MkMZZBiwjQ24IHBIBhfrUXeWcutf1+ecZD9yxWqNqTOV23zz937mdB7U3nAMSEWpZr DoIJpHZKAtMgdlPB9aWQc/wCbkzPxcOZPbMjYtGuUN0RIrr+ipSZhqTrC8ykmn3heb E78n3f5tl3JxXAghzr2+wT5tkaHXanO4JvF9tldaYVEYRIH8UfdtMrONfzvJlueGX3 QGmAvgHeIPy6Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zAf3Sp6cZT88RIWTtJvnhz479A4
Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Apr 2014 21:49:06 -0000

Just to clarify: INFOs are never forked.

An INFO isn't sent until there is an early (or confirmed) dialog. And 
then each INFO is sent within a particular dialog. If the INVITE is 
forked, then *separate* INFOs can be sent, each in one of the dialogs.

	Thanks,
	Paul

On 3/30/14 5:48 AM, Christer Holmberg wrote:
> Hi,
>
>> 2) Trickle ICE INFO with serial forking
>>
>>    a) INVITE from local
>>    b) INVITE is forked by proxy to first remote destination
>>    c) 100 trying is reaching local
>>    d) INFO with Trickle ICE from local
>>    e) INFO is forward by proxy to first remote destination
>>    f) INVITE is forked by proxy to second remote destination
>>    g) Whether INFO has to be forked?
>>
>> It is not mentioned in the draft whether INFO has to be forked to the
>> second remote destination as well. Could you please explain the expect
>> behavior for this scenario.
>
> I am not sure what you mean by the INFO being forked.
>
> When a new fork is created (i.e. when the offerer receives a 18x response from a new destination), whatever candidates have been trickled on previously created fork(s) of course need to be provided also on the new fork.
>
> And, when multiple forks exist, whenever a new candidate is to be trickled, an INFO carrying the candidate needs to be sent on each fork.
>
> I don't see a problem with this, but if it is unclear in the spec then some additional text might be needed.
>
> Regards,
>
> Christer
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email