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

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

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.

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.

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.

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

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.

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?

Reagards

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: Monday, March 29, 2004 2:59 PM
> To: Magnus Westerlund
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [AVT] How is SDP a=fmtp used for RFC 2198?
>
>
> I agree with Magnus' interpretation of the RED parameters, the complete
> list should be specified. However, our intent when writing RFC 2198 was
> never to include so many levels of redundancy: sending 4 copies of each
> frame seems excessive.
>
> Colin
>
>
>
> --> Magnus Westerlund <[e-mail]> writes:
> > Hi Gunnar,
> >
> > See comments inline. However feedback from actual users and
> the authors
> > of RED is kindly requested, to help resolve this problem.
> >
> >
> > Gunnar Hellstrom wrote:
> >
> > > Magnus,
> > > Thanks for the comments on RFC2793bis-03,
> > >
> > > Comment 16 reflects another interpretation of RFC2198 than I
> have done.
> > >
> -----------------------------------------------------------------------
> > >
> > >>16. Section 6.3:
> > >>   "Below is an example of SDP similar to the above example, but also
> > >>    utilizing RFC 2198 to provide redundancy for the text packets:
> > >>
> > >>        m=text 11000 RTP/AVP 98 100
> > >>        a=rtpmap:98 t140/1000
> > >>        a=rtpmap:100 red/1000
> > >>        a=fmtp:100 98/98 "
> > >>
> > >>I think one should point out in this text that one signals only that
> > >one>will use on layer of text redundancy. IF one would use
> three levels
> > >of>redundancy then the fmtp line would read:
> > >>    a=fmtp:100 98/98/98/98
> > >>
> > >
> > >
> ----------------------------------------------------------------------
> > > ----------
> > > I have not understood that from RFC2198.
> > >
> > > This is what RFC2198 says about the FMTP line:
> > >
> ----------------------------------------------------------------------
> > > --- To receive a redundant stream, this is all that is required.
> > > However
> > >    to send a redundant stream, the sender needs to know which codecs
> > >    are recommended for the primary and secondary (and tertiary, etc)
> > >    encodings.
> >
> > I am basing this on this part. As it gives clear indication that one
> > should indicate what generation of redundancy the codec is
> specified for.
> >
> > This information is specific to the redundancy format,
> > >    and is specified using an additional attribute "fmtp"
> which conveys
> > >    format-specific information.  A session directory does
> not parse the
> > >    values specified in an fmtp attribute but merely hands it to the
> > >    media tool unchanged.  For redundancy, we define the format
> > >    parameters to be a slash "/" separated list of RTP payload types.
> > >
> > >    Thus a complete example is:
> > >
> > >        m=audio 12345 RTP/AVP 121 0 5
> > >        a=rtpmap:121 red/8000/1
> > >        a=fmtp:121 0/5
> > >
> > >    This specifies that the default format for senders is redundancy
> > >    with PCM as the primary encoding and DVI as the secondary
> encoding.
> > >    Encodings cannot be specified in the fmtp attribute
> unless they are
> > >    also specified as valid encodings on the media ("m=") line.
> >
> > Also this example clearly indicates that PT=0 (PCM) is used as
> primary,
> > and DVI as secondary encoding. That ranking could not have been done
> > unless the list implies an order from primary to higher degrees of
> > redundancy.
> >
> > > -----------------------------------------------------------------
> > > I cannot from this description read that there needs to be one figure
> > > in fmtp for each generation of redundant data. I rather
> expect the fmtp
> > > line to express possible codecs, with the first one being
> the primary,
> > > and then enumerating the ones used for redundancy taken in any order.
> > >
> > > The payload format is specified per block of text in the
> block header.
> > > Therefore I do not see the need for SDP to specify exactly
> the planned
> > > PT:s per redundant generation.
> > >
> > > Thus
> > > a=fmtp:100 98/98
> > >
> > > Would be enough regardless how many generations of PT 98
> data we intend
> > > to handle.
> > >
> > > OK?
> >
> > I also think that it would be simpler to use the list to indicate all
> > codecs that MAY appear in the redundancy format. However as in my view
> > the text indicates that one should indicate what specific
> configuration
> > of redundancy codecs that should be used. This is also a matter of
> > backwards compatibility, for RED in general. Therefore I seek input on
> > how this has been interpreted and used so far.
> >
> > Cheers
> >
> > Magnus
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > Multimedia Technologies, Ericsson Research EAB/TVA/A
> > ----------------------------------------------------------------------
> > Ericsson AB                | Phone [phone]
> > Torshamsgatan 23           | Fax   [phone]
> > S-164 80 Stockholm, Sweden | mailto: [e-mail]
> >
> >
> > This communication is confidential and intended solely for the
> > addressee(s). Any unauthorized review, use, disclosure or
> distribution is
> > prohibited. If you believe this message has been sent to you in error,
> > please notify the sender by replying to this transmission and
> delete the
> > message without disclosing it. Thank you.
> >
> > E-mail including attachments is susceptible to data corruption,
> > interruption, unauthorized amendment, tampering and viruses,
> and we only
> > send and receive e-mails on the basis that we are not liable
> for any such
> > corruption, interception, amendment, tampering or viruses or any
> > consequences thereof.
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
>
>
> --
> Colin Perkins
> http://csperkins.org/
>



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