Subject: [IPTEL] Call admission control

From: "Erickson Trejo-Reyes" <[email-masked]>
Date: Wed, 14 Jun 2000 17:43:46 +0100

Hi everybody,

Does any of you have some references for specific call admission control techniques that might have been considered for traffic engineering in the IP for avoiding congestion in networks carrying telephony flows? Thanks in advance,

Erickson Trejo-Reyes
University of Leeds
Institute of Integrated Information Systems
[email-masked]
Tel: +44 (113) 233-2019
Fax: +44 (113) 233-2032

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 14 Jun 2000 17:54:49 -0500

Having enough bandwidth is a first step that comes to my mind. Predications
show voice traffic will be only several % points on IP networks and the
Internet, so why bother to complicate life just for voice. My two cents.

Henry
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Erickson Trejo-Reyes
  Sent: Wednesday, June 14, 2000 11:44 AM
  To: James Yu; [email-masked]
  Cc: [email-masked]
  Subject: [IPTEL] Call admission control

  Hi everybody,

  Does any of you have some references for specific call admission control
techniques that might have been considered for traffic engineering in the IP
for avoiding congestion in networks carrying telephony flows? Thanks in
advance,

  Erickson Trejo-Reyes
  University of Leeds

---

From: Larry Cox <[email-masked]>
Date: Wed, 14 Jun 2000 13:39:21 -0700

At 05:43 PM 6/14/00 +0100, Erickson Trejo-Reyes wrote: 

>techniques that might have been considered for traffic engineering in the
>IP for avoiding congestion in networks carrying telephony flows?
>Thanks in advance,

As you are probably already aware, the problem is both very serious and
rather difficult to resolve. In a public Internet environment, even with
significant free bandwidth, packet voice is frequently completely
incomprehensible. Packet jitter can turn voice into nearly completely
random noise. At present, the preferred procedure is to create a separate
network dedicated to voice. The problem with this is a complete negation of
the primary reason for using VoIP. If you have a separate network anyway,
the existing circuit switched network is a known quantity with very high
reliability and voice over ATM is more efficient than voice over IP.
RSVP-TE, Diffserv, and MPLS appear to be the direction that the industry is
going. The combination will allow for traffic engineering, priority of
service for time critical streams, and failure recovery.

You may want to check the MPLS list. They are working with the issues
related to latency and jitter. They are also working toward traffic
engineering and resolving the failure recovery problem. send an email to
<[email-masked]>. I do not remember if subscribe needs to be in the
subject line or the body. I think that I sent both.

Larry

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Billy Biggs <[email-masked]>
Date: Wed, 14 Jun 2000 16:50:17 -0400

Larry Cox ([email-masked]):

> random noise.

  Larry,

  Not that this is the right forum or even the right thread, I'm very
curious about your statements on the unreliability of packet voice over
the public Internet.  I've now had several trans-atlantic telephone calls
over the public Internet, and often use packet voice for shorter range
(100ms avg lag, 20 hops) Internet calls.  64kbps u-law, RTP encapsulated
in each direction.

  I have never experienced the audio to be 'incomprehensible'.  Even with
no traffic shaping or control, and even when talking to people on cable
modems with reasonable amounts of traffic, it's still much better than
most cellphones.

  Do you have any references to papers or web pages which indicate that
strong admission control or traffic management is useful beyond very
extreme networks or specifc cases of heavy bandwidth applications?

  In general, TCP seems back off quite happily.

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]