Subject: RE: [Ieprep] Re: GETS calls placed from corporate PBXs

From: "Gunn, Janet" <[email-masked]>
Date: Mon, 16 Dec 2002 16:19:52 -0500

Just to make clear.

I am not aware of any plan to REPLICATE GETS implementation in the "big I"
Internet.

Some of the "strengths" of GETS are not applicable in the Internet, e.g.
there are no "Network Controls" (such as call gapping) to be exempt from.

But conversely, just because you can't do something in GETS doesn't mean you
shouldn't TRY to do it on the Internet.

Case in point. 
- In GETS, you don't get any special service from the originating handset to
the LEC.  Not because it isn't desirable, but because it isn't practical.
- But in WPS, you DO get special service directly form the originating
handset (queueing for a radio channel).
- If Something analogous is not PRACTICAL in the Internet, so be it.  But
don't use the fact that it is not PRACTICAL in GETS to infer that it is not
DESIRABLE in the Internet.

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Monday, December 16, 2002 2:09 PM
To: Nguyen, An
Cc: 'King, Kimberly S. '; Gunn, Janet; ''ieprep ' '
Subject: Re: [Ieprep] Re: GETS calls placed from corporate PBXs

On Saturday, Dec 14, 2002, at 21:33 America/Montreal, Nguyen, An wrote:
> Two of several GETS features are "trunking queuing" and exemption from
> management control" that give GETS high probability call completion 
> during
> congestion.
>
> 1. Trunk Queuing allows a GETS user to queue his/her calls and wait 
> for the
> next available; and
>
> 2. With exemption, GETS calls don't get blocked.
>
> With these two designed to support GETS, I think GETS gets better 
> service
> than just "best effort".

I believe that is true *within the administrative boundary of 
RBOCs/CLECs
that have contracts with NCS for GETS* provided the 710 area code is 
being
used.

These features are NOT enabled for GETS within my company's PBXs.
They probably are NOT enabled in many companies' PBXs.  They are
reportedly NOT enabled for the outbound call portion in situations
where the end-user is accessing GETS via the 800 (presumably using 800
because 710 is not supported at the end phone handset).

My question was specific to the situation where the end user is on a 
phone
handset that is connected to a corporate PBX where no GETS contract is
in place and 710 is not a supported area code, that is, my question
was not "in general", but in a specific scenario.

The relevance of this, by the way, is that accessing the Internet in an
unplanned manner from a random tail circuit is comparable to accessing
the PSTN from behind a random corporate PBX.  In both cases, it is hard
to pre-plan for any link congestion that might be present.  In the 
Internet
case, congestion is uncommon inside the core even during a crisis, 
whereas
there are credible reports that the PSTN does suffer congestion inside 
its
core during a crisis.

But thanks anyway,

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

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Dec 2002 17:05:09 -0500

> I am not aware of any plan to REPLICATE GETS implementation in the 

Very good to know.  There has been confusion on this point.

> DESIRABLE in the Internet.

Fair enough, but maybe the above caveat about "practical" also means 
that at least
some things (e.g. end-to-end QoS mechanisms getting deployed widely) 
that some folks
desire are not likely to happen either here in IEprep or in the 
deployed Internet.

Of course, there are also various things that might be practical (albeit
tedious to get all the end-user contracts in place and configure all 
the boxes),
many of which (e.g. edge router CoS) have already been disussed here.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 16 Dec 2002 16:22:23 -0800 (PST)

On Mon, 16 Dec 2002, Gunn, Janet wrote:
    > Just because you can't do something in GETS doesn't mean you

I'm in complete agreement.  The strengths of VoIP and the Internet
generally are vastly different than those of the PSTN, and I think we can
expect to see a few really useful functions which would be difficult to
perform in another environment.  For example:

1) Handset-to-handset cryptographic authentication.

2) Handset-to-handset evaluation of loss and per-handset-pair tuning of
   forward error correction.

3) Persistent connections, which stay up through radical re-routing of the
   actual path of the traffic, whether with user-perceivable drop-outs or
   not.  This is similar to the robustness which the cellular network
   displays during cell-to-cell handoffs, but can potentially withstand
   much longer periods of temporarily disruption.

4) Multiply-hubbed partial-mesh call-bridges, so that a conference call
   can withstand the loss of one or more audio-stream multiplexing
   facilities or loss of connectivity between some participant pairs,
   without actually dropping anyone off the call.  This is a big one,
   wich can only be done in a packet-switched environment.

I'm sure many of you can imagine many other similar advantages.

                                -Bill