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

Christer Holmberg <> Thu, 18 June 2015 06:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 72D2F1B2FE5 for <>; Wed, 17 Jun 2015 23:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rJ0J7jOBiQVX for <>; Wed, 17 Jun 2015 23:11:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF3461B2FE4 for <>; Wed, 17 Jun 2015 23:11:38 -0700 (PDT)
X-AuditID: c1b4fb30-f799f6d000000faf-ab-558261189934
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5B.30.04015.81162855; Thu, 18 Jun 2015 08:11:37 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 08:11:36 +0200
From: Christer Holmberg <>
To: Roman Shpount <>, Paul Kyzivat <>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00
Thread-Index: AQHQqSZchTPWJK9az0yTRVvUcTD/x52xAcuAgADGs2A=
Date: Thu, 18 Jun 2015 06:11:35 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8EE03DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3VlcysSnU4NojZoupyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZkzYuZCm4ll1x/vVntgbG BxldjJwcEgImEl8372SEsMUkLtxbz9bFyMUhJHCUUeLlj0nsEM5iRol/Z88AVXFwsAlYSHT/ 0wZpEBHwlujr62AHsZkFVCRenb7MCmILC5hLHDq1lhWkXASofG1THES5lUR71w+wXSwCqhIb p09gAynhFfCV+PihBiQsJFAk8WvjKiYQm1MgUGL+rtdg5YxAp30/tYYJYpO4xK0n85kgThaQ WLLnPDOELSrx8vE/sK0SAooSy/vlIMrzJdo7nrCA2LwCghInZz5hmcAoOgvJpFlIymYhKZsF NIlZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st 2cQIjLyDW34b7GB8+dzxEKMAB6MSD6+CWlOoEGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwbllo93WSI8e3mzJHe6UaZZLf2H/MF876bh7xsf+Cgei2Jz9+ OE5YnX9yyuwghcCaXZYn0ju6C5rfzcy4IXy83YfPJLRdPXZF+9bPouzXf2ZtSavJvnr0aHzP r/K5jf8eBFz+oO5QMankQmD63h9bKxy6qx7XTv70dxNjsPTDACkVo+Qdx9rrlFiKMxINtZiL ihMBMU5wTp0CAAA=
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 06:11:41 -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.



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