Re: Question about global uniqueness of dtls-id

Hi,

On Sep 1, 2017 1:28 PM, "Cullen Jennings" <[email protected]> wrote:

I don't think that works for a bunch of reasons but to start with the 2nd
offer to A would not have the right information in the o= lines of the the
original offer/answer. In many cases (including WebRTC) that would cause it
not to work as a re-offer. Other issues like it A was receiving video, the
old I frame state might end up getting used. If A was sending, it would not
know the the other end was now missing reference frames.


Third party call control is something that is widely used as well. You are
correct that offer generation requires that information in o= line must be
preserved, but I am not aware of any reason why offer with non matching o=
line will not be processed if received from remote end point. This is very
common and will likely cause interop problems if prohibited.

I think new I frame should be always sent when new DTLS association is
established. I need to double check but I think it is already required
after ICE restart. If not, new I frame is a good idea after ICE restart or
communication transport 5 tuple change.


SIP can deal with that by using the invite with replaces stuff from rfc3891
so that the 2nd offer sent to A can clearly be a new session not a reoffer
on the old one. Similar things would be done by webrtc so it could deal
with it by just creating a new PC for the 2nd offer and transfering the
tracks over to the new PC.


Replaces header support is optional and it is not always enabled. In any
case, despite the fact that some call scenarios can be implemented using
other methods, third party call control is widely deployed and used, which
means offer/answer compliant end points would have to deal with such
scenarios.


Section 5.2.2. of JSEP discussed this a bit how the o= lines need to be the
same for a reoffer.


This section describes how offer is generated by JSEP compliant end points.
I do not think it puts those limitations on what offers should be processed
when received from remote, not necessarily JSEP compliant, end points, such
as WebRTC gateways.

Regards,
Roman Shpount

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic