|
Satish,
I had a cursory look over this document. It's
not readily apparent to me why we would need a redundancy mechanism other than
that which is defined in RFC 2198. We have identified a few areas in RFC
2198 that we could improve upon, mostly just for clarification.
It seems that the primary reason is that timestamps
are not necessarily the best match for non-audio media flows. I will not
disagree with that statement. At the same time, most of the voice band
data communication flows, including fax, modem, and DTMF data are
time-sensitive. I believe that the only example that might stand out here
is the text/t140 format and that is not a voice band data flow. However,
audio/t140 is a voice band data flow and it is more sensitive to time. We
transmitting between two GWs, we would want that media to be relayed with
minimal delay, so we would be concerned with timestamps.
As for the text/t140 example I mentioned, I
certainly hope that we do not try to change the basic redundancy scheme already
used with RFC 2793, as this would cause problems for software that utilizes
this scheme already.
As for the proposed new redundancy format, how does
a device differentiate one format from another? Is there a bit somewhere
that indicates which payload format to follow?
Paul
|
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt