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 E93A71A03EC for <mmusic@ietfa.amsl.com>; Wed, 2 Apr 2014 14:49:21 -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 j8MewXuZy7gi for <mmusic@ietfa.amsl.com>; Wed, 2 Apr 2014 14:49:17 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0FF1A03D9 for <mmusic@ietf.org>; Wed, 2 Apr 2014 14:49:17 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id l9cc1n0030QuhwU519pDgS; Wed, 02 Apr 2014 21:49:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:8c32:6f0f:1357:9383]) by omta02.westchester.pa.mail.comcast.net with comcast id l9p91n00D3oQGAY3N9p94q; Wed, 02 Apr 2014 21:49:13 +0000
Message-ID: <533C85D5.3060700@alum.mit.edu>
Date: Wed, 02 Apr 2014 17:49:09 -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=1396475353; bh=W4bz8kpbmruAROdEl5ZLLifyvnwLBBsnNvKicgpwOWU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B2WCnhAmgMShzlqjx8rjavGlGKIJRXuy82XIsdqEjAB9U8lwCNzQaQNfpv0Dnb7Ep tyarJjCmOKqsv+f5XuhTPLM+a+wLgDcRtIYkA6HndocY3WuLglqzUjzZP5VSbMmeIQ dpvl6NlMZgrwLrmcbqqrkUjQ8ufrudZYTO0eD/mfObF8+5UnGUsy2SDduFtb6kEvTc GYT9PlHz9ZQIek32LSFjR9G8nG5f9tipA9lqCfGeliRMKrdQwW3c3VU+0iB4fj2Gcq 9Mvg07r2oXDxEJQHrO29Nj7noyrfsU+yw0UolVLD4DzOZCf/BgRNn0jxyWvELzBD5I yJ51xsdzky0uA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rZsO6s8S1kJG8cHsqAoxhNri7vA
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:22 -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