WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> In your previous mail you wrote:
>> > - Abstract page 1: implosion -> explosion (things which can implode are rare :-)
>> [Qin]: RFC4588 referenced by this document is using "implosion". So
>> I think it should be fine to use the same term in this document.:-)
> => RFC 2887 too. IMHO it is time to stop this "implosion" madness and
> to return to a correct language (BTW we have the same problem in French, for
> an unknown reason the word implosion is often used in place of explosion
> when it has the exact opposite meaning...).
[Qin]:I can understand it is more sensitive to use "explosion" than "implosion"in France.:-)
However my understanding is implosion seems to mean feedback messages overwhelm the network capacity.
If we change "implosion" into "explosion", we seems to change the meaning of "feedback implosion",
that is to say, "feedback explision " means feedback message has already paralyzed the network. The Network dies :-).
I am aware that RFC4585 also use "feedback implosion". Since this draft references RFC4585,
Isn't draft-ietf-avtcore-feedback-supression-rtp in accordance with RFC4585?
>> [Qin]: Okay.
>> > - 4.2 page 7: if the SSRC is an IPv4 address the "set to 0" is not very correct.
> => the real problem is what is the SSRC. No spec is very clear, so the
> assumption it is not an IPv4 address is right IMHO. (i.e., I withdraw this comment)
>> Also it is easy to cause SSRC collision if IPv4 address can be
>> choose as 0.0.0.0 which is broadcast address.
> => BTW 0.0.0.0 is *never* a broadcast address (it could be the only address
> in this case :-).