Re: [AVT] How is SDP a=fmtp used for RFC 2198?

[Colin Perkins <[e-mail]>]

--> "Gunnar Hellstrom" <[e-mail]> writes:
> On number of redundant generations for text transmission.
> ---------------------------------------------------------
> There is a need for one original and three redundant copies as the
> RECOMMENDED default for text transmission. That will meet the service
> requirements of <1% character error rate in conditions when voice is
> barely usable ( from F.700 & F.703 ). That can be in a society crisis
> situation when the network gets congested, or in next outbreak of worms
> crawling the Internet.
> Audio can be used for voice, and video for sign language down to around
> 30% packet loss. It can be a good goal to maintain usable text
> transmission at that packet loss rate.
> 
> Try the calculator in http://packetizer.com/iptel/toip/cercalc.html
> and find that you need 3 levels of redundancy to get under 1% character
> error with 30% packet loss. The character error figure for text coded
> text is at the bottom of the page.
> 
> It is not expensive. The RECOMMENDATION is to send text packets with 300
> ms intervals, and only when there is something to transmit. The
> redundancy levels take little space compared to the packet and RTP
> header.

I'd expect the gain from sending 3 levels of redundancy to be minimal
compared to a single delayed redundant packet.

> 3 generations of redundant data may sound excessive, if you have a
> network where loss is usually under 1%. But, if there is a risk of 30% in
> a crisis situation, you should follow the recommendation.

As noted in the security considerations section of RFC 2198:

   Whilst the addition of low-bandwidth redundancy to an audio stream is
   an effective means by which that stream may be protected against
   packet loss, application designers should be aware that the addition
   of large amounts of redundancy will increase network congestion, and
   hence packet loss, leading to a worsening of the problem which the
   use of redundancy was intended to solve.  At its worst, this can lead
   to excessive network congestion and may constitute a denial of
   service attack.

I believe the same issue is applicable to text streams, and accordingly do
not agree that sending 3 levels of redundancy is appropriate.

> On SDP for RFC2198
> --------------------
> If nobody have used RFC2198 for more than one generation of redundancy
> before, we are maybe free to document an interpretation of the SDP a=fmtp
> parameter in the most reasonable way. I think that is that the
> slash-separated list enumerates payload types that may be used in the
> session. Then, during media transmission, the PT parameters in the
> RFC2198 header indicates what coding was selected by the transmitter for
> that occasion.

Agree.

> The "secondary", "tertiary" etc payload types, may rather indicate a
> level of preference rather than the position among the redundant
> generations.

No.

> In the Introduction of RFC2198, the definition of fixed sets of payload
> types communicated out of band is mentioned as a cumbersome approach,
> while the freedom to select payload type for secondary information and
> indicate it in the same packet is the preferred method used in RFC2198.
> 
> I would not expect the SDP parameters needed to use RFC2198 to work
> against the promoted idea of the flexible coding of RFC2198.
>
> Therefore, I think, that I can specify a=fmtp: 100 98/98   and mean that
> PT 98 is used as primary, and PT 98 is used for any number of generations
> of secondary coded redundant data. No tertiary choice of coding is
> specified, meaning no third choice of coding.

No, this is not correct. The syntax "a=fmtp:100 98/98" means that payload
type 98 is used for the primary and secondary, and that there is no third
level of redundancy. 

> Here is the excerpt of RFC2198 introduction that supports this view:
> -------------------------------------------------------------------------
>  A modified version of the above solution could be to decide prior to
>    the beginning of a conference on a set a 32 encoding combinations
>    that will be used for the duration of the conference.  All tools in
>    the conference can be initialized with this working set of encoding
>    combinations.  Communication of the working set could be made through
>    the use of an external, out of band, mechanism.  Setup is complicated
>    as great care needs to be taken in starting tools with identical
>    parameters.  This scheme is more efficient as only one byte is used
>    to identify combinations of encodings.
>    It is felt that the complication inherent in distributing the mapping
>    of payload types onto combinations of redundant data preclude the use
>    of this mechanism.
> 
>    A more flexible solution is to have a single payload type which
>    signifies a packet with redundancy. That packet then becomes a
>    container, encapsulating multiple payloads into a single RTP packet.
>    Such a scheme is flexible, since any amount of redundancy may be
>    encapsulated within a single packet.  There is, however, a small
>    overhead since each encapsulated payload must be preceded by a header
>    indicating the type of data enclosed.  This is the preferred
>    solution, since it is both flexible, extensible, and has a relatively
>    low overhead.  The remainder of this document describes this
>    solution.
> ---------------------------------------------------------------
> Clear, isn?t it?

The text you quote has nothing to do with the MIME signalling for RFC 2198,
and instead motivates the choice of a payload format with embedded payload
type numbers.

We have had a tool that supports multiple levels of redundancy since 1997,
although such is rarely used becase it offers little benefit.  If one does
use multiple levels of redundancy, it is signalled by specifying each level
of coding on the SDP line, for example:

	m=audio 49170 RTP/AVP 0 3 5 98
	a=rtpmap:98 red/8000
	a=fmtp:98 0/5/3

If the same coding is used for multiple levels of redundancy, it must be
specified multiple times.

Colin

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt