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

Paul Kyzivat <> Thu, 18 June 2015 16:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE3241B2A02 for <>; Thu, 18 Jun 2015 09:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lH_6yjhzjMnj for <>; Thu, 18 Jun 2015 09:59:03 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B50411B29F7 for <>; Thu, 18 Jun 2015 09:59:03 -0700 (PDT)
Received: from ([]) by with comcast id hsyz1q0024zp9eg01sz3rW; Thu, 18 Jun 2015 16:59:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id hsz21q00D3Ge9ey01sz29p; Thu, 18 Jun 2015 16:59:03 +0000
Message-ID: <>
Date: Thu, 18 Jun 2015 12:59:01 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Christer Holmberg <>, Roman Shpount <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1434646743; bh=BIH+D3bo6rBM0nP+WOJg373KM3/GBtV/qsctMcV2ruo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=okiqfzZVTw07jp7rrJokxFSQ6n2PRs9Xw8fH5l3aRAARW36HuGwjZVmOUFiJZk/QP gWeQjq2wyexTTJAANmAvh5PMlsX2aDoaFI6zNmYE4UmsS7ny7vx1bgBntLLzJX/UrV 8kSVxE90EQe//McTnSfn+TotFAAnoNV2cqooT6iyTT1x+24cA1EdadxwXsto5oe0xj Yf+eFuZN21BpqgMTbvGgV3urwn1lnBevpIOetMg2kk5+UMGYe5i/tjUvnHt3eh/Y+S dAtVWj1qua+rVVXI13pJ4rboJ/fuwbjtyp9Y1TkVaDMy7LHimQtKcW7H1sG9elfRtz /3YtaB+xsMJAw==
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: Thu, 18 Jun 2015 16:59:05 -0000

On 6/18/15 2:11 AM, Christer Holmberg wrote:
> Hi,
> I guess I don’t have too much to add to what Roman said.
> But, from a DTLS perspective, forking is the same as e.g. call transfer.
> Also in that case the local candidates may stay the same, while the
> remote ones change.

There is a difference. In the case of forking you might want to keep 
both forks. (Typically not, but a conference server might.) And even if 
you only want to keep one long term, you may need to keep more than one 
during early media, until you know which one to keep long term.


> Regards,
> Christer
> *From:*mmusic [] *On Behalf Of *Roman Shpount
> *Sent:* 17. kesäkuuta 2015 23:19
> *To:* Paul Kyzivat
> *Subject:* Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00
> 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 combinations.
>     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