Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

[Paul Kyzivat <[e-mail]>]

On 4/2/15 4:43 AM, Christer Holmberg wrote:

>>>> 4. In case of ICE, the underlying transport is considered changed if ufrag and entire candidate list changed on >either side of the call (missing from the current specification).
>>>
>>> We need to be clear what we mean by “entire candidate list”. Do you mean a new SDP, which only contains candidates that have never been used before during the session?
>>>
>>> Obviously, the IP address:port properties may still be the same, so I guess the ufrag would have to be different – as you say.
>>
>> BUT, I think someone in Dallas had a comment on why ufrag can’t be used. Justin? Ekr?
>>
>> Ufrag change can be due to iCE re-start (which means fingerprint cannot change) or due to device change (fingerprint can change). There is no easy way to distinguish the two.
>
> Correct.
>
> One possible way would be to use the SDP connection attribute, with a "new" value. However, usage of the attribute is currently not allowed for SRTP-DTLS.
>
> There was also a suggestion to use SIP replace, but we need to define an SDP mechanism.

Well, when using SIP replace the session-id (o-line) should change. And 
it is supposed to remain unchanged within a dialog.

So from an SDP perspective a totally new session-id value can be taken 
as an indication. But this affects the complete SDP session, not just a 
single m-line or bundle.

ISTM that a=connection:new is the better answer. The forbidding of this 
for SRTP-DTLS seems like a bug rather than a feature. Does anyone know 
the reason for it?

	Thanks,
	Paul