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

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
>