[MMUSIC] Trickle ICE for SIP Questions

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

Return-Path: <emil@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9289C21F9BB6 for <mmusic@ietfa.amsl.com>; Wed, 3 Jul 2013 07:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AFMTtMqk3Hjh for <mmusic@ietfa.amsl.com>; Wed, 3 Jul 2013 07:13:54 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5119511E81A0 for <mmusic@ietf.org>; Wed, 3 Jul 2013 07:13:54 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id k10so5284542wiv.7 for <mmusic@ietf.org>; Wed, 03 Jul 2013 07:13:48 -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 :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=TzihQPLf5/PLJ9EhwcpUp8JtxQfIuTm6inMypkvbx+I=; b=jv4/OhAv0f5CkyH8qYW3boGP++K0h7fBBPOW0W11kfe5JOLb8QHQoHzF+TRzbMTHqW wSBv0nRseqS+S1sJf/tTYS+vJ3L2FBnT4tAIvfC6F7kl1FO9wRFaHTe158KuJ/wYTT5b 48yHSuhewfEGxu90r9Pw4XIU/R567nQXvUIiKvhjlLK/QQPz6R42Z0/CsaGJLzZk5nVL xCV9OUibfw+qYA9YDJ18zOePg2IZ9hIvx7RKZNAyPyEIElKT/+VwvPH7gg13G5C+t777 lUAorGF2JtmXWtCz9YUK36kX1wsGtxEbj7mm1up0hTK/WsT/C6F8Tm8qyNjlwhQ3AQDW wpng==
X-Received: by with SMTP id u11mr637683wib.61.1372860828265; Wed, 03 Jul 2013 07:13:48 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPSA id fo10sm29062729wib.8.2013. for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 07:13:47 -0700 (PDT)
Message-ID: <51D43186.2010907@jitsi.org>
Date: Wed, 03 Jul 2013 16:13:26 +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: MMUSIC IETF WG <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQljlNnp28L0CljM29rfpB4Zg9HuuYfAda/BF2Cq7eAI78wic6cJkAp2IWKMsNcIIEuNK2E2
Subject: [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 14:13:59 -0000

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.

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.


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!