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

[Christer Holmberg <[e-mail]>]

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.

Regards,

Christer

From: mmusic [mailto:[e-mail]] On Behalf Of Roman Shpount
Sent: 17. kesäkuuta 2015 23:19
To: Paul Kyzivat
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00

On Wed, Jun 17, 2015 at 1:52 PM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>> 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