Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01

Roman Shpount <> Mon, 22 June 2015 17:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E73EA1A7012 for <>; Mon, 22 Jun 2015 10:30:24 -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 KfOIskwaRs-x for <>; Mon, 22 Jun 2015 10:30:23 -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 F0D421A90C4 for <>; Mon, 22 Jun 2015 10:30:22 -0700 (PDT)
Received: by igblr2 with SMTP id lr2so58294711igb.0 for <>; Mon, 22 Jun 2015 10:30:22 -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=HTrZgjneIXYLGVEIrEPx3PEgJUFRPP/WP1gXCHjtybE=; b=RIc2dCpIGgSQspkgCfOTVmxyOGRLT3i9E56U+TXl6bP/YAhEePK0OPQYjidHNrzB9p XnCyLrIC0fjXySOM0EX0nptLd/oJ6y4+TxY561wM1/68By5TG3H8pShHzkODfiPgMY45 bycm3vy2j8s+Xn5Px5TRsV+FhvYnyMWGKZ5v9D0vZbvANyzJIa3qOjAi6d836pGvh2fZ 3XR6ysA98nH0cRkl9H5g2LfW53lfhCvmuPRv8mw3FMaco0r6blardXVXQ3FDwjq79OiZ eJCQLBtQZLpaKX7rcJOBdX8U6IZ2SG9C3hz5MFV080VdjKuEF6rAZsNPUitWEHrJGx92 pbxg==
X-Gm-Message-State: ALoCoQkhY/6KJL0OExkbj0Q3kQoa2NgrO95mh+/IzJ3zchhl1JrVYJoYAnw/SjpeiaSOONtVOM/8
X-Received: by with SMTP id yw3mr26791093icb.97.1434994222358; Mon, 22 Jun 2015 10:30:22 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 140sm13180478ion.16.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 10:30:21 -0700 (PDT)
Received: by igbiq7 with SMTP id iq7so58248945igb.1 for <>; Mon, 22 Jun 2015 10:30:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id be5mr26932294icc.2.1434994220171; Mon, 22 Jun 2015 10:30:20 -0700 (PDT)
Received: by with HTTP; Mon, 22 Jun 2015 10:30:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 22 Jun 2015 13:30:20 -0400
Message-ID: <>
From: Roman Shpount <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="bcaec5196a2dbfa37305191ea06d"
Archived-At: <>
Cc: "" <>, Paul Kyzivat <>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01
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: Mon, 22 Jun 2015 17:30:25 -0000

On Mon, Jun 22, 2015 at 3:39 AM, Christer Holmberg <> wrote:

> > One thing to keep in mind here, that unless ICE restart was initiated by
> the offering side (i.e. it had a different ufrag/pwd even if it specified
> > connection:exisiting), answering side cannot allocate a new transport.
> Answering side is simply not allowed to respond with a new ufrag/pwd
> > unless new ufrag/pwd was used in the offer. In cases where offer has the
> same ufrag/pwd, answering side must use connection:existing and issue > a
> new offer to setup new transport and new DTLS association.
> That's a good point. Is that a generic ICE rule, or something we need to
> define for DTLS in the draft?
This is a generic ICE rule defined in RFC 5245 9.2.2 (

Unless the agent has detected an ICE restart from the offer, the username
fragments, password, and implementation level MUST remain the same as used
previously.  If an agent needs to change one of these it MUST restart ICE
for that media stream by generating an offer; ICE cannot be restarted in an

I do not think we need to restate this, but we need to specify how this
will affect DTLS setup. Primarily there are two things we want to mention:

1. When ICE is used, new DTLS association can only be setup in an answer,
if it is an answer to ICE restart.

2. If an ICE offer is received, which requires a new DTLS association,
either due to fingerprint or setup role change, or due to "connectiion:new"
attribute, and this offer does not have new ufrag/pwd, then it cannot be
handled. This would indicate an error condition, and media line would need
to be refused with m-line port 0 or the whole offer would need to be
refused with an error response. After that connection would need to be torn
down or renegotiated with a new offer with new transport and DTLS
Roman Shpount