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

Christer Holmberg <> Thu, 18 June 2015 17:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D3711B2A05 for <>; Thu, 18 Jun 2015 10:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1qJjYjSRAcJj for <>; Thu, 18 Jun 2015 10:07:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35C851B29C9 for <>; Thu, 18 Jun 2015 10:07:35 -0700 (PDT)
X-AuditID: c1b4fb30-f799f6d000000faf-df-5582fad5ecce
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DF.98.04015.5DAF2855; Thu, 18 Jun 2015 19:07:33 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 19:07:32 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>, Roman Shpount <>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00
Thread-Index: AQHQqSZchTPWJK9az0yTRVvUcTD/x52xAcuAgADGs2CAAJPUgIAAI5Kg
Date: Thu, 18 Jun 2015 17:07:32 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvre7VX02hBtfmqlhMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKmLXhGnvBNuWKf7NvsDQw HlDqYuTkkBAwkfhyYgUzhC0mceHeerYuRi4OIYGjjBIH921lhHAWM0r8O3aVpYuRg4NNwEKi +582SIOIgLfEhPmr2UBsZgEViVenL7OC2MIC5hKHTq1lBSkXASpf2xQHUe4mseFuIyNImEVA VeLSehaQMK+Ar8TXtROZIDbdYJT4/L4X7B5OAR2JNet3ghUxAt32/dQaJohV4hK3nsxngrhZ QGLJnvNQ94tKvHz8jxXCVpJYdPszE8guZgFNifW79CFaFSWmdD9kh9grKHFy5hOWCYxis5BM nYXQMQtJxywkHQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbSwS2/DXYwvnzueIhR gINRiYdXQa0pVIg1say4MvcQozQHi5I474zNeaFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GOey8Vdnbe1c9mK6yOHSMic1tqq4+Xe/ambGTdXU/zmtgvPjWnGG6LnKmZfWbTcy2+56955g Z/YJbtdik+mnIl3meb78XzVJZtb0ZO82Y9kNTAbpC99uNRb6rOJd+4M7tYV1g3hgBpflp+1u xy/mL8pLcP0fc3Fnh29SxPZvOTWPldYdnFUkp8RSnJFoqMVcVJwIAHkxue+GAgAA
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 17:07:37 -0000


>> 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.

Sure, there may be a difference in how long you maintain both DTLS associations. But, never the less, you still need separate DTLS associations.



> *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