Subject: Re: [Ieprep] a little homily - benefits of multicast

From: Alistair Munro <[email-masked]>
Date: Fri, 05 Apr 2002 10:51:07 +0100

Hi Dean,

You are right, I am talking c**p and have got my G's mixed up. Sorry if there was
any confusion.

> G711 (every 8 msec one 64 byte voiceframe is produced) codec is not
> compresing voice at all. It is 64kbps per voice call on top of that is
> the IP and other headers, comes to aprox 80kbps. So, you are saying at
> roughly 80 percent packetloss speech was intelligible?

I'll check what codec I am using on the IP phones, but it is definitely a standard
8Kbps one which generates around 16 Kbps of RTP frames per direction (as measured
by my LAN analyser and by the element itself). It is a G.7xx, but obviously I do
not mean the 64 Kbps one.

The speech was barely intelligible at 10 Kbps, at around 30% - 40% maximum loss.
For bursty competing streams available bandwidth would often exceed 10 Kbps. For
CBR loads intelligibility is very poor. It would never pass toll-quality analysis.

>  Did you use some compression on datagrams or? Because with
> that big packetloss, G711 is not producing good quality, at least in
> my experience.

No compression, just off-the-shelf stuff. Plug in, find the gatekeeper and go -
which is what IP telephony ought to be...

There are many lower rate codecs that would run happily in 10 Kbps. But this is not
the point.

As far as recommendations from this WG are concerned, Fred Baker's requirements
document refers to a possible QoS configuration. If emergency services base their
DiffServ set up on this basic framework then they will have to choose bandwidth
allocations, drop precedences, etc. to suit their traffic mixes, applications (i.e.
codecs) and the quality they want to deliver. I am trying to draw attention to the
many possibilities that they could draw on. We will not be specifying codecs but we
must give guidelines on deployment.

Regards,

Alistair

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Alistair Munro <[email-masked]>
Date: Fri, 05 Apr 2002 13:57:59 +0100

Hi Ken,

>I have an open ear to adding text to the current draft on subjects it 
>doesn't cover, but i'll take a very cautious approach regarding codecs
>because i have the (possibly mis)conception that the subject really
>gets rather implementation/deployment specific.
>
Yes, I would leave people to make their own decisions on implementation, 
deployment etc.

I was wondering if there were any issues in the interworking of 
different operational networks, but decided that protocols exist to 
arbitrate the selection of codecs (does SIP do this? my H.323 setup 
seems happy to switch) and transcoding at boundaries is (a) done, (b) 
not an issue for this WG, except possibly to remark on QoS and bandwidth 
allocation. Any comments on this will apply to video and voice.

Regards,

Alistair

-- 
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile) +44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.degree2.com, http://www.u4eagroup.com

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 05 Apr 2002 13:38:15 +0100

hi,

> As far as recommendations from this WG are concerned, Fred Baker's
> requirements document refers to a possible QoS configuration. If
> emergency services base their DiffServ set up on this basic framework
> then they will have to choose bandwidth allocations, drop precedences,
> etc. to suit their traffic mixes, applications (i.e. codecs) and the
> quality they want to deliver. I am trying to draw attention to the many
> possibilities that they could draw on. We will not be specifying codecs
> but we must give guidelines on deployment.

one thing to keep in mind is that Fred's requirement draft uses GETS and 
the more general concept of IEPS as a foundation for putting forth
requirements.  and these Requirements stress no specific solution, though
the draft does raise issues and an example or two as food for thought.

the Framework document starts the process of providing some guidance
in terms of  IETF protocols and services.  in certain places, it provides
some specific guidance (such as pointing out the optional Resource-header
field for SIP), and in others it just says what exists in a given area
along with a "buyer beware" attitude where it seems appropriate.

so, to a degree, it does what you state at the end of your above comment,
but it does so with respect to GETS-like service as a target model.  this
keeps the draft grounded so that it doesn't jump all over the place.

cheers,

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 17 Apr 2002 09:41:07 -0500

>not mean the 64 Kbps one.

The "64 Kbps one" is not any G.7XX as measured by packet analyzers. 64kbps
circuit mode (or source BW) throughput is actually ~ 80kbps packet mode (50
samples/sec) at L3 and could be from 85kbps (Ethernet framing) to 106kbps (when
incorporating over ATM) on the wire with the additional headers and is the
G.711 codec

If you are measuring 16kbps in a single direction with your analyzer - then the
audio has been compressed 4:1 from inbound BW (of 64kbps) - and it's likely the
G.728 codec being used - which is employed primarily as the audio along with
H.261/263 Video -- it's rarely used for strictly voice.

just an fyi here...  

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com