Hi
I have read the document and some comments below, many of the comments
are likely out of the scope for this group but I deemed that some
background info is good. It is not intended as a market pitch for
various standards but some reference to current state of the art
technology is necessary to get things into a context.
===========
Ch. 3 : "Playout as little as 150ms are often problematic". In 3GPP
TS22.105 specifies 150-400ms end to end delay with 400ms being the upper
extreme point. End to end delays have traditionally been of great
concern but there is a trend that this concern is being less an issue as
echo suppression algorithms are getting better. As a comparison circuit
switched cellular telephony (GSM) has an end to end delay of ~220ms and
this service is used with success.
===========
Ch. 3.1: The AMR codecs (AMR-NB and AMR-WB) use rate switching which is
seamless in the aspect that only a quality difference is experienced
when rate is switched up or down (i.e there are no clicks or pops). In
fact 3GPP TS26.114 specifies rate adaptation as a means to cope with
coverage problems or congestion. The rate adaptation for the above
codecs has a "dynamic range" of 1:3 (AMR-NB : 4.75kbps to 12.2kbps,
AMR-WB : 6.60kbps to 23.85kbps)
The rate adaptation feature was originally intended for circuit switched
wireless telephony (GSM) but is very useful for VoIP aswell.
Other examples of codecs and their dynamic range in bitrate
AMR-WB+ : 1:9
(5.2kbps mono to 48kbps stereo)
ITU-T Q9 : (scalable speech/audio codec being standidized now) 1:8
(8kbps to 64kbps)
Both have seamless or very close to seamless rate-switching.
For VoIP there is also an opportunity to reduce packet rate as a means
to avoid congestion. A reasonable "dynamic range" is say 1:4 (1 speech
frame/packet to 4 speech frames/packet) although 3GPP TS26.114 allows
for even more. Switing to higher packetization delays puts some extra
burden on the buffering algorithms in the receiver and will increase the
end to end delay but it is no showstopper.
To conclude, I would say that rate switching using modern speech codecs
is a lesser concern than pointed out in the draft, of course quality
goes down with lower bitrate but 5kbps VoIP with 0% packet loss is way
better than 12kbps VoIP with 10% packet loss.
Note that the term "dynamic range" is not too widely used, there is
perhaps a better term available but I cannot figure out what it may be.
===========
Ch 3.3: "goes totally idle for sometimes several seconds". I don't fully
agree here. Although possibly true for older standards, all modern
speech codecs that implement DTX (discontinuous transmission) transmit
SID (silence descriptors) at regular intervals, the SID's give a coarse
description of the background noise and the payload size of the SID is
~5-6 bytes. The intention of these SID's is to give the user a
comfortable feeling when the other party is silent (total silence may
otherwise give the impression that the line is dead). The regular
transmission is to avoid that the background noise change too abruptly
when the other party starts to speak again he/she may have moved to
another location during the silent period. The interval between the
SID's vary between the standards. The older codecs for GSM transmitted
SID's every 500ms. The AMR codecs mentioned above transmits SID's every
160ms, the reason behind this frequent update is however related to the
bitrate adaptation loop in AMR for GSM networks. In perspective of this
I would not expect long idle times other than if a user press the call
on hold button.
===========
Some 3GPP references that might be useful, it is not the holy bible but
may nontheless be good for comparison.
+ Services and service capabilities (delay requeirements)
http://www.3gpp.org/ftp/Specs/html-info/22105.htm version 7.1.0 table
1 (delay requirements)
+ IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling
and interaction
http://www.3gpp.org/ftp/Specs/html-info/26-series.htm version 7.1.0
chapter 10.2 (adaptation signaling for VoIP)
Regards
Ingemar
> -----Original Message-----
> From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx]
> Sent: den 20 augusti 2007 17:21
> To: Ingemar Johansson S (LU/EAB); Sally Floyd; Eddie Kohler
> Cc: Gorry Fairhurst; Golam Sarwar; Sebastien Ardon; 'dccp'
> working group; Roksana Boreli
> Subject: RE: DCCP for VoIP
>
> Hi Ingemar,
>
> This thread got started while I was on vacation, so I'm a
> little late jumping in, but...
>
> The basic topic here is meant to be part of
> draft-ietf-dccp-tfrc-media-02.txt -- please check that out,
> especially section 4.3.1, which is meant to deal with two-way
> interactive applications. It doesn't yet incorporate some of
> the latest developments (CCID4 and FR), but it should be
> useful (there's been some information on this thread that'll
> help me update it). Any comments would be appreciated.
>
> Tom P.
>
> > -----Original Message-----
> > From: Ingemar Johansson S (LU/EAB)
> > [mailto:ingemar.s.johansson@xxxxxxxxxxxx]
> > Sent: Monday, August 20, 2007 2:38 AM
> > To: Sally Floyd; Eddie Kohler
> > Cc: Gorry Fairhurst; Golam Sarwar; Sebastien Ardon; 'dccp' working
> group;
> > Roksana Boreli
> > Subject: RE: DCCP for VoIP
> >
> > Hi
> >
> > One issue that may be important to know in this aspect is
> that there
> > will probably need to be some limit to how often feedback is
> transmitted
> > esp. for VoIP applications with low birate.
> >
> > Low bitrate VoIP typically have a bitrate of 5-12kbps (payload
> bitrate)
> > and in 3GPP the bearers that are specified (today) for
> these services
> > have an RTT in the range 200-700ms depending on load and coverage
> > situation. One of the worries regarding DCCP is that
> feedback cost too
> > much and having more than one feedback per RTT will further increase
> the
> > system load.
> >
> > One solution may be that an extra condition is added that specifies
> that
> > feedback should not consume more than X percent of the total
> transmitted
> > bitrate combined with the rule that feedback should be transmitted
> > atleast once per RTT.
> > Maybe a little odd formulation but hopefully the intention is
> > understood. Anyway, with this rule feedback would not consume an
> > unreasonable amount of BW for low bitrate VoIP applications.
> >
> > Ingemar
> >
> >
> > > -----Original Message-----
> > > From: Sally Floyd [mailto:sallyfloyd@xxxxxxx]
> > > Sent: den 20 augusti 2007 02:27
> > > To: Eddie Kohler
> > > Cc: Gorry Fairhurst; Golam Sarwar; Sebastien Ardon; 'dccp'
> > > working group; Roksana Boreli
> > > Subject: Re: DCCP for VoIP
> > >
> > > > This sounds like a very interesting idea. While the
> > > documents specify
> > > > that feedback is sent once per RTT, since this is what TFRC
> > > > recommends, I think more frequent feedback is a fine
> idea even for
> > > > low-loss-rate/low-RTT scenarios (twice or four times per
> > > RTT, say?),
> > > > and probably mandatory for high-RTT scenarios. My
> guess is Sally
> > > > would agree. Perhaps someone could suggest a change to the
> CCID3/4
> > > > language.
> > >
> > > TFRC (RFC 3448) only has a smalll discussion about
> sending multiple
> > > feedback packets per RTT. E.g., in Section 6:
> > >
> > > "If the sender is transmitting at a high rate (many
> packets per
> > > RTT)
> > > there may be some advantages to sending periodic feedback
> > > messages
> > > more than once per RTT as this allows faster response to
> > > changing RTT
> > > measurements, and more resilience to feedback packet loss."
> > >
> > > TFRCbis (draft-ietf-dccp-rfc3448bis-02.txt) adds more
> clarification
> > > about what needs to be done when the receiver sends multiple
> > > feedback
> > > packets per RTT. From feedback from Arjuna. In Section 6:
> > >
> > > "If
> > > the receiver was sending k feedback packets per RTT, step (4)
> of
> > > Section 6.2 would be modified to set the feedback timer to
> expire
> > > after R_m/k seconds. However, each feedback packet
> would still
> > > report the receive rate over the last RTT, not over
> a fraction
> of
> > > an RTT."
> > >
> > > I think it is good to allow multiple feedback packets per RTT.
> > > However, I personally wouldn't be inclined to make it the default
> > > recommendation for all scenarios, for CCID 3/4, until
> there has been
> > > a little more experience with it. Just in case there is some
> > > drawback or implementation issue that pops up...
> > >
> > > - Sally
> > > http://www.icir.org/floyd/
> > >
> > >
> > >
>
>
