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

Emil Ivov <> Sun, 30 March 2014 20:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F6121A08D4 for <>; Sun, 30 Mar 2014 13:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CD_fqIdiwxoM for <>; Sun, 30 Mar 2014 13:37:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42BC41A07D7 for <>; Sun, 30 Mar 2014 13:37:03 -0700 (PDT)
Received: by with SMTP id u57so3839199wes.8 for <>; Sun, 30 Mar 2014 13:36:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U5HGFsuTwzDBtoPiUvBFKdXA2TTP6kuDRQ9m22s9dtQ=; b=O40fPFh/LLAUJiFHzQlp494Bos5pt/hdqLFvyp8s+RCQuak7xty+XvtIK7KxQGTN/9 R2mAvXHVtTkiFoOY0hLsPJTWJug1k+sOQgwa9bU7llkUBD+mDnZ/pcdguNH4hGWgPv4M /nRb4UwBO0YFCvbAFYkPZAe3imW2FiA6ks7MzMUHOaBINZW2L7aAsbf2eIH/UWfRaM6g zHJ4CSB7quZRiysDPnu2mIujyqUTNKyuY5e2KRoANmLY67Pxc3B1CySQlotF9zi9wto0 f/XpExMM9v2iZIvPbwD7i5sdvPA/3nfwQQubfknGByJL/rS6MXOlNU89MVSZ0NUpSXla 3CjQ==
X-Gm-Message-State: ALoCoQmsqulliWKzht9Fnh7+tKMQ+xt//WUPEAKLCWisn8TDc7ykjJ31fAIL5YErOcXAFkE66s0j
X-Received: by with SMTP id hv7mr7413444wib.38.1396211819482; Sun, 30 Mar 2014 13:36:59 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPSA id k4sm22284272wib.19.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Mar 2014 13:36:58 -0700 (PDT)
Message-ID: <>
Date: Sun, 30 Mar 2014 22:36:56 +0200
From: Emil Ivov <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Christer Holmberg <>, Parthasarathi R <>, "'Enrico Marocco (TiLab)'" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Mar 2014 20:37:05 -0000

On 30.03.14, 11:48, 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.

Making sure we are on the same page:

1. These additional INFOs need to be trickled by the ICE agent that 
generated them in the first place.

2. This would happen as an explicit step that is visible to the TU and 
the ICE agent. That is, it's not something that would be automatically 
handled by a SIP stack, by simply resending all the INFOs from the first 
prong of the fork to the second one.

3. Those INFOs may or may not contain the same candidates (e.g. the 
agent may have chosen to use different port numbers for that prong) and 
they may or may not be the same number (e.g. if the agent is reusing 
addresses, it may decide to send them all in a single INFO, rather than 
in a sequence of INFOs).

Do we agree?