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

[Paul Kyzivat <[e-mail]>]

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.

	Thanks,
	Paul

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