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

["Gunnar Hellstrom" <[e-mail]>]

Conclusions for RFC2793bis usage

1. We need a fmt=100, 98/98/98
In order to specify transmission of one primary and two level of
redundancy.

2. One primary and three levels of redundancy was regarded excessive, so we
reduce the default to one primary and two redundant transmissions. That
means low load and high reliability.
Terminal software will not be extremely smart. They do not know if the
other party is on a 3G IP multimedia connection, or a bad TV-cable Internet
connection where a lot of packets are lost. You must start with an
assumption that 20% packets may be lost.


3. Each generation of redundant info gives quite good reliability increase.

Look at this calculation:

For RFC2793bis text transport in text form, this is the theory:

Assume that the risk of loosing a packet is p
The risk of loosing also next text packet is also p

The bad case is only when both are lost. The likelihood for that is p*p .

You can check with 50% loss and sending two packets. There are totally four
outcomes.

lost -not lost
lost - lost
not lost - lost
not lost - not lost

Only one out of four is unsuccessful. that is 25%.

0.5 * 0.5 = 0.25 the probability calculation is valid.

If you add one more redundancy level, the likelihood of all three lost is
p*p*p

With real figures, 20% packet loss and three transmissions give 0.2 * 0.2 *
0.2 = 0.008 =0.8%total loss.

Regards

Gunnar

-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Wednesday, March 31, 2004 5:32 PM
> To: Gunnar Hellstrom
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [AVT] How is SDP a=fmtp used for RFC 2198?
>
>
> --> "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