Re: [MMUSIC] Trickle ICE for SIP Questions

Emil Ivov <emcho@jitsi.org> Wed, 03 July 2013 19:29 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77AE21F854E for <mmusic@ietfa.amsl.com>; Wed, 3 Jul 2013 12:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 33-Zgtq1IHGh for <mmusic@ietfa.amsl.com>; Wed, 3 Jul 2013 12:29:22 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D139021F99BB for <mmusic@ietf.org>; Wed, 3 Jul 2013 12:29:21 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id q56so450169wes.17 for <mmusic@ietf.org>; Wed, 03 Jul 2013 12:29:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=v8cvW4f9cRAnnGmrlOdq8KgEyM9PXB2opxP1E1SAPqg=; b=EHxjcQINfBs2vgF2/T3iZZ0RdO+SNGrb4yRD5SHrqndT4Vx1CJstst85BWVgEr/C8V pcwXSXuzUPxiUuSUvJeL+YvPbQD7//35GdVSzXF8bM9InqWVf+IFQHvtqfj8Qi4CScA9 FzcuW1IvzY8yoLi7N01OJrJLdoeLSFf18UNM+LXwJP9Vv3URTfPKVq8CKMcqkt8NcIXL 67N4nGPveSwigLkWhHqV/64h90QZMEPvnbArAeK4zmDdVrSq8HW+tpxXEImbg9F+IV5Y b5zWoShFusBuLx0rZ8H69GLF6q6iKhwe8DSnTTJpMORQCDyL4cutiFLNxp4hNWQ6hHqn ld6Q==
X-Received: by 10.180.207.43 with SMTP id lt11mr18915148wic.57.1372879760880; Wed, 03 Jul 2013 12:29:20 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:1deb:1465:36b2:68fe]) by mx.google.com with ESMTPSA id f8sm30507245wiv.0.2013.07.03.12.29.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 12:29:20 -0700 (PDT)
Message-ID: <51D47B8E.1090200@jitsi.org>
Date: Wed, 03 Jul 2013 21:29:18 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <51D43186.2010907@jitsi.org> <E41E201C-E622-4477-82E7-9F76AA5F49B4@cisco.com>
In-Reply-To: <E41E201C-E622-4477-82E7-9F76AA5F49B4@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlKT2/KTEIE3X4/ZsU/WPI/FgyRUBouhfpCbjKsje2hvvUv0Q6lF0WJ7NCvNWulang8fDRy
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jul 2013 19:29:26 -0000

Hey Dan,

On 03.07.13, 21:01, Dan Wing wrote:
>
> On Jul 3, 2013, at 7:13 AM, Emil Ivov <emcho@jitsi.org> wrote:
>
>> Hey all,
>>
>> Christer, Enrico and I are preparing the next version of Trickle
>> ICE for SIP. Now that discussions on BUNDLE and the plans seem to
>> be winding down, we wanted to run a few questions by the working
>> group.
>>
>> Q1: Making reliable provisional responses and PRACK mandatory.
>> Obviously this would be nice to avoid, so the question is: is there
>> a reasonable mechanism to achieve this (and by reasonable, we mean
>> something that wouldn't be harder than implementing support for
>> PRACK).
>>
>> There was some discussion about this back in April and there was a
>> suggestion for implementing a 5245-style hack where the answerer
>> basically resends the 180 until it knows that it has been
>> received.
>>
>> 5245 uses connectivity checks for this (i.e. it stops 180
>> retransmissions when the first connectivity check is received) but
>> we don't have that option here since the 180 may contain either
>> none or only host candidates so there are strong chances that no
>> binding request would be received on them.
>
> I might work, because each re-transmission would probably have
> additional candidates (because the STUN/TURN transactions will have
> completed), and thus more likely that those re-transmissions
> (containing those additional candidates) would result in the remote
> endpoint sending a STUN binding request.

If we do it cumulatively, then yes. We can then move to INFOs the moment 
we get either a first check (which would more often be the case with 
half trickle) or a first INFO request (which would be the case for full 
trickle).

This could indeed work. However it would also imply that we keep sending 
candidates cumulatively even in the INFO requests since we wouldn't know 
how many of the 180s got through.

This makes me slightly uncomfortable as it would imply that someone 
would have to maintain state on the sending side, and do a number of 
comparisons on the receiving side ...

Emil

--
https://jitsi.org



>> Thomas also suggested a second option which would be to also use
>> INFO requests with trickled candidates as an indication that 180
>> was received. This however wouldn't work with half trickle so we
>> are basically back to vanilla ICE for all (non-re) INVITEs.
>>
>> Another option would be to mandate an INFO request with
>> "end-of-candidates" in response to the 180, but that would be just
>> the same as mandating PRACK support.
>>
>> Thomas also suggested that the answerer can start sending INFOs
>> right after it sends its answer in the 180 and then it can just
>> resend the 180 if the INFOs result in a 481 response.
>>
>> Personally I think this could potentially be made to work, but it
>> would imply a level of complexity that considerably exceeds PRACK
>> support.
>>
>> Opinions?
>>
>> Q2: How do we send INFOs? Are they blocking or do we just send them
>> in parallel? If the latter, then what happens when an INFO fails
>> because it is received out of order? Do we just tell the
>> application to resend the candidates asap?
>>
>> This also leads to the following question:
>>
>> Q3: What exactly do we send in INFOs? Just the latest batch of
>> freshly learned candidates or all candidates we've learned so far?
>> Dale suggested that if we do this cumulatively we wouldn't need to
>> worry about the case with the out-of-order INFOs from Q2 since the
>> information gets resent anyway. A drawback here would obviously be
>> that this adds more complexity for trickle ICE users (WebRTC
>> applications specifically)
>>
>> A third option would be to allow both and leave it to the
>> application.
>>
>> Comments are most welcome!
>>
>> Emil