Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00

Roman Shpount <> Wed, 17 June 2015 20:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 40FF51A0032 for <>; Wed, 17 Jun 2015 13:18:50 -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 uhs7Z66o_xn7 for <>; Wed, 17 Jun 2015 13:18:48 -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 DFBF41A001D for <>; Wed, 17 Jun 2015 13:18:47 -0700 (PDT)
Received: by igblz2 with SMTP id lz2so45362779igb.1 for <>; Wed, 17 Jun 2015 13:18:47 -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=WIXLYiwl9Q13TjdDNg02Y1QM9v3cp9ku7Xl7Pck5fr8=; b=Jy0McZUq5reF3O5FD/l4wJ7PWicWeHO4dhGwa+VPxSIQGREpTdxqY1Nv0y16Ht12Tg JwJZMCC0CgnNeVAXXta8zkcnJ7ZB3QGpzBBFjIdy10p75oy9Qml+OgfFb5MZ0bBPDRjx XuLJhP11wz+QTL59UQvq+JAKkx5zzRLdIvUB4dYbDfQ3XN7EBg1hhOZU20R8Mt97FThQ obs3MQEz3ZqD9QEQ0IhP3sIAQoASNvD27fGhwAuSqPGZkS34bF0J7zsubCkSxUkg/TGj fQTjGIbDq7Ly1ZmCVUFwKn7O4aKxpOUszBEyA9L+YOgdR/j85YZajQx9t5TFHDOdS8D4 1vKw==
X-Gm-Message-State: ALoCoQlLFuXaHI07sAXzNZYFgRW8M6lHU0uGS3GvAb6QUvHi4ylriB7F1aaVkF2YrK+fgfWZ/4lz
X-Received: by with SMTP id cs5mr38266541igb.4.1434572327417; Wed, 17 Jun 2015 13:18:47 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 82sm3272595ioh.3.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 13:18:46 -0700 (PDT)
Received: by igbos3 with SMTP id os3so2490039igb.0 for <>; Wed, 17 Jun 2015 13:18:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id d71mr10585825ioe.29.1434572325385; Wed, 17 Jun 2015 13:18:45 -0700 (PDT)
Received: by with HTTP; Wed, 17 Jun 2015 13:18:45 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 17 Jun 2015 16:18:45 -0400
Message-ID: <>
From: Roman Shpount <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="001a1140eadadbfe320518bc65b1"
Archived-At: <>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00
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, 17 Jun 2015 20:18:50 -0000

On Wed, Jun 17, 2015 at 1:52 PM, Paul Kyzivat <> wrote:

> I'd also like to dig a bit more into forking. As noted in section 4.5, if
> forking occurs, then separate DTLS associations will be made with each
> callee. In this case, those distinct DTLS associations will share common
> host candidates. (Can they also end up sharing some relay candidates?) Yet
> the 5-tuples will differ.

The 5-tuples would typically be different and that should be enough for
de-mux. Sharing the same host or relay candidates should not be a problem.

One thing to keep in mind, would be that if allocation of new relay
candidates is done before the exciting relay candidates are released, then
new relay candidates will be different. If relay candidates are released
before allocation, then relay candidates can end up being the same, which
can cause problems. Relay candidates that were closed due to being unused
by previous ICE session, can be reused since no existing DTLS traffic would
be flowing over them. The same closing order restriction also applies to
the host candidates. Otherwise if you release local host candidates before
allocating new one, you might end up with the same local address/ports

> Now, suppose that the same endpoint then needs to make a change. For
> instance, maybe it needs to change its fingerprint. In this case it needs
> to create new DTLS associations. In that case it must also use new host
> candidates. Is it permitted to use the same (new) candidates to recreate
> *both* DTLS associations? I can't see any reason why not. I also don't see
> any specific prohibition in the text. But it would be good to be explicit
> about it.

If I understand what you are asking, It is possible to use the same host
candidates to update multiple DTLS associations that are created due to
forking. The only requirement is that when DTLS association is updated, the
set of host and related candidates (relay, reflexive) is new for
communications within this specific m= line on connection to this specific
end-point. The end goal is to create a new 5-tuple. This being said, such
usage would be fairly uncommon.

Roman Shpount