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

Christer Holmberg <> Sun, 30 March 2014 21:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BC8BE1A08D7 for <>; Sun, 30 Mar 2014 14:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K3ms--fGrH6K for <>; Sun, 30 Mar 2014 14:01:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1329E1A08D1 for <>; Sun, 30 Mar 2014 14:01:39 -0700 (PDT)
X-AuditID: c1b4fb28-b7fd58e000007bb5-86-53388630f462
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8C.FB.31669.03688335; Sun, 30 Mar 2014 23:01:36 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sun, 30 Mar 2014 23:01:35 +0200
From: Christer Holmberg <>
To: Emil Ivov <>, Parthasarathi R <>, "'Enrico Marocco (TiLab)'" <>
Thread-Topic: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING
Thread-Index: AQHPS/02PLTBD8bHIkyTiQF+pdjMC5r59hMAgAAnDLc=
Date: Sun, 30 Mar 2014 21:01:34 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja5Bm0WwwcX/whZrdk5gsWi542Ux dfljFovJn/pYHVg8liz5yeTx/02gx4f5X9g9Ws71sgewRHHZpKTmZJalFunbJXBldO3byFpw U7Di6aqp7A2MN3m7GDk5JARMJOYc+cACYYtJXLi3nq2LkYtDSOAko8SJqwsYIZwljBL7Dv1h 7WLk4GATsJDo/qcNEhcR6GWU2LtuNgtInFlAXeLq4iCQQcICARLPv/1mAwmLCARKrLvHChIW EbCS+P9nFtguFgFVifUTJjOD2LwCvhI3fp0CiwsJZEl8O3GOEaSVU0BToudmGkiYEei076fW MIHYzALiEreezGeCOFlAYsme88wQtqjEy8f/wI6UEFCSmLY1DaJcR2LB7k9sELa2xLKFr6G2 CkqcnPmEZQKj2CwkU2chaZmFpGUWkpYFjCyrGCWLU4uLc9ONDPVy03NL9FKLMpOLi/Pz9IpT NzECo+zglt8aOxi7r9kfYpTmYFES562a2RkkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTHg cV35BOnPwct2ucp/vJt1olK+wvsRq8cxnrrFayeomL9mWS5780V128NDC5cknZee7K7l+rRJ VmbuRn4Bi8OtsrNtDnY94uEI+ZfmX6mzVWDl7Tau+ws9Hgo+46rV819gIbfmggZLvta8R/lP Wf+17Svqb+B80PZn2p9589/OWpd1zttcvliJpTgj0VCLuag4EQAZl9PrgAIAAA==
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 21:01:42 -0000


>>> 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.

It would be handled by the ICE agent. 

>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).

Correct. The INFOs would contain whatever candiates are "valid" at that given point. The point was that, IF candidates have previously been trickled on other forks, and they are still "valid", they need to be trickled also on the new fork.

>Do we agree?

We always do :)