Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

Roman Shpount <> Wed, 08 April 2015 18:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 74B5C1ACE1F for <>; Wed, 8 Apr 2015 11:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w1okckwDEw7p for <>; Wed, 8 Apr 2015 11:44:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 393B01A8BC0 for <>; Wed, 8 Apr 2015 11:44:29 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so92654349ied.1 for <>; Wed, 08 Apr 2015 11:44:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=stvBjewqKA7CdSQ/C47QisOTSAax8HUUm8a00Fy/OT8=; b=CIGT1mWDFHFdJYLWsqywKtXzSy9J18PUL35PPmmED1e5hgFn1lOYil+ojYbJb+JtNJ qajoaLC6kGjvufEHIqbjnmcOjNoVDEHLApkxfghHGCQCVrx6JJpgwCcGJzjliylfyWsP jTkBZ3blhmz4sBTfG9a3lfFX8Y55b28dkzYEhWVbYJ7etkC1DOUQ6/6xRZwrJrcUict2 gKxz+kDGQ89kmd/NGt3kys4u8Ilr6InxZ19KTQCkkzAf8ZPxRqMe0gopynsVOjloyKMr N/ywsbc+s2cdprhDR0OBX4a6IWaZ3Pvh15Uo0pLb1ypiyNJmYW+rl2ZJwpx/JoVpahfT Cnww==
X-Gm-Message-State: ALoCoQniImUD9qoOmp03Oxn2eUR95o9SdevxglMYQwDcWYH9M/CzcG6QnvzwWxUNIhIXFhDDmai8
X-Received: by with SMTP id c22mr31676433iod.81.1428518668652; Wed, 08 Apr 2015 11:44:28 -0700 (PDT)
Received: from ( []) by with ESMTPSA id f11sm702057iod.7.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 11:44:27 -0700 (PDT)
Received: by iggg4 with SMTP id g4so47765164igg.0 for <>; Wed, 08 Apr 2015 11:44:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id 80mr3914517iol.18.1428518665453; Wed, 08 Apr 2015 11:44:25 -0700 (PDT)
Received: by with HTTP; Wed, 8 Apr 2015 11:44:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 8 Apr 2015 14:44:25 -0400
Message-ID: <>
From: Roman Shpount <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary=001a113f8f5a9c08f005133aeb61
Archived-At: <>
Cc: "" <>, Christer Holmberg <>
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact
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: Wed, 08 Apr 2015 18:44:31 -0000

On Wed, Apr 8, 2015 at 1:01 PM, Paul Kyzivat <> wrote:

> On 4/7/15 7:13 AM, Christer Holmberg wrote:
>> Hi,
>> Any comments on this from others? We need to solve it.
>> Anyone has issues with allowing connection:new for SRTP-DTLS and
>> SCTP-DTLS, and use that as a trigger to re-negotiate DTLS?
> ISTM that this is being considered tactically. Maybe that is the best for
> now, but perhaps there should be consideration of a strategic approach to
> this as well.
> What I mean is that this seems to be a back handed way to introduce
> multipath support into protocols (specifically DTLS) that don't support it.
> Perhaps multipath ought to be officially added to all the protocols that
> potentially need ICE, and then ICE would simply be one way to populate the
> paths.
This will still leave the question of how to determine when the multipath
protocol running over ICE communicates with the new end point (i.e.
connection needs to be re-established) or when this is a path update and
the connection needs to be preserved. For ICE there is no easy way to
determine if what currently is happening is ICE-restart on the existing
connection which should allow existing mutlipath protocol session to
continue vs setting up ICE to a new end point which would require new
connection setup. This problem currently affects DTLS, but I assume this
will apply also to other multipath protocols which require externally
initiated connection handshake when running over ICE. This can be addressed
on the protocol side (connection new attribute which will apply to DTLS) or
on ICE side (some sort of indication if this is a new end-point or
re-start). Protocol side change seemed to be the less disruptive and more
backwards compatible option in case of DTLS.

The reason DTLS is running into problems with ICE, is due to the fact that
it was not design to run multiple sessions over the same connection and
does not allow setting up a new session unsolicited using transport
messages only, which are properties of RTP for which ICE was originally
designed. Extending DTLS so that it is possible to multiplex several DTLS
sessions over the same connection, and initiate new session setup using
transport level messages, would be a better strategic solution.
Unfortunately this is not going to be backwards compatible and would
further complicate design and implementation.

>From my personal point of view, DTLS in combination with ICE is a design
mess. It would be much cleaner and strategic if instead two separate
protocols this was a single protocol which was responsible
for authentication, encryption negotiation, connection path discovery, path
updates, and communication consent. These are closely related tasks and
ideally they should be handled together instead of one on top of the other.
Roman Shpount