Paul,
I disagree that these are proprietary solutions.
The first is a matter of policy and so falls into a slightly grey area, but
ideally the standard would say something like 'only send presentation
restricted information to an entity that you trust to honour the request.'
The second is definitely NOT an action you could take at a proprietary level
as the standards body still holds the right to define new IEs. Any such
action would have to be approved by the standards body. When I said '.…
[View More]..YOU
could take further ownership...', the 'you' was intended to refer to SG16.
As such a change is small and localised, it would be safe to implement it
even if it was mentioned only in a determined document (which is the way the
procedure is supposed to work after all anyway!) which could be achieved at
the Chile meeting. A fix in the ASN.1 would have to wait for the decided
version as that needs to wait until all such additions are present.
Pete
=============================================
Pete Cordell
pete.cordell(a)btinternet.com
=============================================
-----Original Message-----
From: Paul Long <Plong(a)SMITHMICRO.COM>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 11 May 1999 21:53
Subject: Re: caller ID and implementer's guide
>Pete,
>
>Of course one can do anything with proprietary solutions, which is what you
>have described in both cases here.
>
>Paul Long
>Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM]
> Sent: Tuesday, May 11, 1999 2:36 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: caller ID and implementer's guide
>
> My two cents - each worth one cent each...
>
> 1) You should only send private information in a clear text field
to
>an
> entity that you trust to honour the request not to display it. If
you
>know
> enough about the entity to trust it, you probably know enough about
it
>to
> know whether it will accept octet 3a.
>
> 2) If you must send this information to an entity that you don't
know
> anything about, you could take further ownership of the use of
Q.931
>and
> define a new IE and IE identifier (such as 0x6e or hi-jack one of
the
>ids
> that you are very unlikely to use - 0x43) to mean 'calling party
>number with
> presentation restriction'. This would have the same format as a
>normal
> Q.931 calling party number.
>
> Pete
>
> =============================================
> Pete Cordell
> pete.cordell(a)btinternet.com
> =============================================
>
>
[View Less]
Pete,
Of course one can do anything with proprietary solutions, which is what you
have described in both cases here.
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM]
Sent: Tuesday, May 11, 1999 2:36 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: caller ID and implementer's guide
My two cents - each worth one cent each...
1) You should only send …
[View More]private information in a clear text field to
an
entity that you trust to honour the request not to display it. If you
know
enough about the entity to trust it, you probably know enough about it
to
know whether it will accept octet 3a.
2) If you must send this information to an entity that you don't know
anything about, you could take further ownership of the use of Q.931
and
define a new IE and IE identifier (such as 0x6e or hi-jack one of the
ids
that you are very unlikely to use - 0x43) to mean 'calling party
number with
presentation restriction'. This would have the same format as a
normal
Q.931 calling party number.
Pete
=============================================
Pete Cordell
pete.cordell(a)btinternet.com
=============================================
[View Less]
My two cents - each worth one cent each...
1) You should only send private information in a clear text field to an
entity that you trust to honour the request not to display it. If you know
enough about the entity to trust it, you probably know enough about it to
know whether it will accept octet 3a.
2) If you must send this information to an entity that you don't know
anything about, you could take further ownership of the use of Q.931 and
define a new IE and IE identifier (such as 0x6e or …
[View More]hi-jack one of the ids
that you are very unlikely to use - 0x43) to mean 'calling party number with
presentation restriction'. This would have the same format as a normal
Q.931 calling party number.
Pete
=============================================
Pete Cordell
pete.cordell(a)btinternet.com
=============================================
-----Original Message-----
From: Paul Long <Plong(a)SMITHMICRO.COM>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 11 May 1999 17:05
Subject: Re: caller ID and implementer's guide
>Karl,
>
>H.225.0 is the _referencing_ Recommendation for Q.931. Therefore, H.225.0
>can--and quite often does--modify aspects of Q.931. One of the many ways
that
>H.225.0 modifies Q.931 is by requiring that the octet 3 extension bit in
the
>calling party number IE be set to 1, which precludes the presence of octet
3a.
>It does not say that it _should_ or _may_ be set to 1; it says that it
>"_shall_ be set to '1'." Therefore, discussion of what a receiving EP
shall
>do when the extension bit is set to 0 is kind of moot, because this bit is
>always set to 1 for communication between compliant EPs starting with
version
>1.
>
>However, we can discuss the behavior of a compliant EP in communication
with a
>non-compliant EP which sends a SETUP with the octet 3 extension bit in the
>calling party number IE set to 0. Upon further consideration of your
previous
>post, I have to agree with you that an EP shall ignore the IE and
optionally
>send STATUS and that it clearly shall not clear the call or accept the IE
but
>ignore octet 3a.
>
>Here's the only completely safe solution I can think of that fulfills
>everyone's needs, if not wants.
>
>1) State in the Implementers Guide that the calling party number IE is only
>included if presentation is allowed. We don't need to say anything about
not
>encoding octet 3a because this is already precluded.
>
>2) Extend the H323-UU-PDU type in v3 with the following component and allow
>the calling party number to be placed in there. Border entities move the
value
>between the real IE on the SCN side and this IE proxy on the H.323 side.
>
> callingPartyNumberIE OCTET STRING SIZE(2..131) OPTIONAL
>
>If present, the calling party number can be placed in either location but
not
>both, so on the H.323 side a v3+ EP could always place the calling party
>number in the IE proxy or place it in the real IE if presentation is
allowed.
>
>How about this solution? It's straightforward, easy to implement, maintains
>the integrity of H.323, doesn't set a bad precedent, and maintains
>interoperability among all shipping and future products. It's admittedly
>inelegant, but the only elegant solution is to go back in time a few years
and
>rewrite H.225.0v1.
>
>Paul Long
>Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Karl.Klaghofer(a)ICN.SIEMENS.DE
>[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE]
> Sent: Tuesday, May 11, 1999 5:49 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: AW: caller ID and implementer's guide
>
> Paul, Chris, Glen,
>
> 1) I have to agree with Chris, the nonStandard field is not
suitable
>to
> carry standardized information, due to the mentioned reasons.
>
> 2) I have thought about the alternative Chris proposed: I think to
put
>the
> presentation indicator bits in a new standardized
H.225.0/Setup-UUIE
>field
> to control the handling of the presentation of Calling Party Number
IE
> contents is not "save" either, since an endpoint (not yet
supporting
>this
> additional coding) would display the Calling party Number contents
>although
> the intention of the calling party was probably NOT to display it
at
>the
> destination (in case of "presentation restriction" being set).
>
> 3) I did not hear any opinion on the expected error procedures in
>H.225.0
> upon receiving optional information elements having a content error
?
> Again, if I follow Q.931, section 5.8.7.2 - which should be the
source
>for
> H.225.0 - then a receiving endpoint not knowing the proposed "new"
>octet 3a
> in Calling Party Number IE, would find octet3/bit8 set to "0" and
>would
> (acc. to Q.931) treat this as an information element contents error
of
>an
> optional information element and therefore ignore the IE but
process
>the
> message.
> This has the advantage that no unintended display of a restricted
>number
> would take place. It has the disadvantage that if 3a is set to
>"presentation
> allowed", the number would not be displayed either. Solution: In
the
> Implementors Guide we can say that octet 3a in H.225.0v2 shall only
be
>set
> with "presentation restriction". If the presentation shall be
allowed,
>NO
> octet 3a shall be sent (no octet 3a means "presentation allowed"
per
> default).
>
> Regards,
>
> Karl
>
[View Less]
Below are the minutes for the call May 11th - please let me know if I have
missed anything, or not captured what you think happened.
Nancy
--------------------------------
Minutes of Megaco/H.gcp call May 11/99 10am-12pm ET
Participants from both the IETF Megaco WG, and ITU SG16 were present on the
call. A total of 20 people called in (I am listing them here - some names
are missing, and some are probably spelled wrong..): Radika Roy, Brian
Rosen, Nancy Greene, John Segers, Paul Sijben, Mike …
[View More]Buckley, Tom Taylor,
Bryan Hill, Glen Freundlich, Rich Ruben, Mike Brown, Hong Liu, and about 9
others.
Results are summarized here, and are open for discussion on the mailing
lists. (Actions are prefaced by **.)
Results:
-----------
1) Procedures for continued cooperation between SG16 and IETF
- agree that the protocol should not unduly complicate the case where MGs
are handling only IP Telephony and not multimedia.
- agree to keep this in mind when dealing with issues such as mono vs
multimedia contexts, etc.
- upcoming SG16 in Chile will address issues such as how to handle
multimedia in the protocol, whether to describe the termination descriptors
using SDP-like syntax or H.245-like syntax. An output of call flows would be
useful.
- ** Progress made in Chile will be documented and posted to the IETF
megaco(a)standards.nortelnetworks.com list by Tom Taylor
- Discussion is encouraged to continue on the megaco mailing list as always,
and there will be an audio call the week after the SG16 meeting to once
again gauge consensus between the two groups.
- even if the H.gcp document is Determined in the ITU SG16 Chile meeting,
the IETF and SG16 can still evolve the document together. Final White
Document text for ITU is due Oct/1999. In the IETF, plan is for the document
to go for WG Last Call in July/99.
2) Documents update
- outstanding issues list - contained in H.gcp, and Tom Taylor has a list as
well, and may post an update to it.
- New version of H.gcp should be out this week (Bryan Hill)
- Ascend SG16 contribution, still not available to the megaco mailing list.
Essence is need to decide whether to tunnel signalling primitives in the
device control protocol, or in Sigtran.
3) mono vs multi media context
- not resolved, still need to compare messages and parameters needed for
each using a series of test cases.
- for H.320 or H.324 MGs, Tom Taylor sees the need to have H.245 running on
the MG
4) SDP syntax vs H.245 syntax
- still need to see call flows, concrete proposals for each method.
- ** Brian Rosen will write up a proposal for termination descriptors - it
won't be SDP and it won't be H.245 - it will be what we need ("minimum
average pain solution")
5) Naming of terminations
- seem to agree that we do not want to have semantics implied by the name.
- need a property in Add that indicates the termination class for the
termination
- move termination class into the termination descriptor?
6) Termination Class - needed?
- question came up whether we need termination class, or whether packages
are enough - each termination would have a set of packages it supports.
- what is a termination class? A group of packages.
- Problem: some DS0's will support MF, some won't, or "I can support 12 DS0s
with MF if there are only 3 G.726 codecs in use". Need to be able to express
this.
- ** Conclusion: rethink termination classes
- if it is not obvious that removing them helps, then leave them,
- need a way to concisely express the properties of any termination or
group of terminations
- need support for provisioning of termination classes at the MG, and
MGC.
- need to support capabilities/resource limitations that span the MG,
such as "I can support 10 G.711 and 3 G.726 codecs simultaneously", and
variations.
- and finally, make sure we do not complicate the simple case! Need
examples.
7) Description of test cases
- ** Tom Taylor will send these out this week, and they will be used to
build call flows, which will be the basis for comparing variations on the
protocol (e.g. mono vs multimedia contexts, ...)
8) Next Audio Call
Sometime during the week after the ITU-T SG16 meeting - date and time will
be posted to the two mailing lists.
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
[View Less]
Karl,
H.225.0 is the _referencing_ Recommendation for Q.931. Therefore, H.225.0
can--and quite often does--modify aspects of Q.931. One of the many ways that
H.225.0 modifies Q.931 is by requiring that the octet 3 extension bit in the
calling party number IE be set to 1, which precludes the presence of octet 3a.
It does not say that it _should_ or _may_ be set to 1; it says that it
"_shall_ be set to '1'." Therefore, discussion of what a receiving EP shall
do when the extension bit is set to …
[View More]0 is kind of moot, because this bit is
always set to 1 for communication between compliant EPs starting with version
1.
However, we can discuss the behavior of a compliant EP in communication with a
non-compliant EP which sends a SETUP with the octet 3 extension bit in the
calling party number IE set to 0. Upon further consideration of your previous
post, I have to agree with you that an EP shall ignore the IE and optionally
send STATUS and that it clearly shall not clear the call or accept the IE but
ignore octet 3a.
Here's the only completely safe solution I can think of that fulfills
everyone's needs, if not wants.
1) State in the Implementers Guide that the calling party number IE is only
included if presentation is allowed. We don't need to say anything about not
encoding octet 3a because this is already precluded.
2) Extend the H323-UU-PDU type in v3 with the following component and allow
the calling party number to be placed in there. Border entities move the value
between the real IE on the SCN side and this IE proxy on the H.323 side.
callingPartyNumberIE OCTET STRING SIZE(2..131) OPTIONAL
If present, the calling party number can be placed in either location but not
both, so on the H.323 side a v3+ EP could always place the calling party
number in the IE proxy or place it in the real IE if presentation is allowed.
How about this solution? It's straightforward, easy to implement, maintains
the integrity of H.323, doesn't set a bad precedent, and maintains
interoperability among all shipping and future products. It's admittedly
inelegant, but the only elegant solution is to go back in time a few years and
rewrite H.225.0v1.
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
From: Karl.Klaghofer(a)ICN.SIEMENS.DE
[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE]
Sent: Tuesday, May 11, 1999 5:49 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: AW: caller ID and implementer's guide
Paul, Chris, Glen,
1) I have to agree with Chris, the nonStandard field is not suitable
to
carry standardized information, due to the mentioned reasons.
2) I have thought about the alternative Chris proposed: I think to put
the
presentation indicator bits in a new standardized H.225.0/Setup-UUIE
field
to control the handling of the presentation of Calling Party Number IE
contents is not "save" either, since an endpoint (not yet supporting
this
additional coding) would display the Calling party Number contents
although
the intention of the calling party was probably NOT to display it at
the
destination (in case of "presentation restriction" being set).
3) I did not hear any opinion on the expected error procedures in
H.225.0
upon receiving optional information elements having a content error ?
Again, if I follow Q.931, section 5.8.7.2 - which should be the source
for
H.225.0 - then a receiving endpoint not knowing the proposed "new"
octet 3a
in Calling Party Number IE, would find octet3/bit8 set to "0" and
would
(acc. to Q.931) treat this as an information element contents error of
an
optional information element and therefore ignore the IE but process
the
message.
This has the advantage that no unintended display of a restricted
number
would take place. It has the disadvantage that if 3a is set to
"presentation
allowed", the number would not be displayed either. Solution: In the
Implementors Guide we can say that octet 3a in H.225.0v2 shall only be
set
with "presentation restriction". If the presentation shall be allowed,
NO
octet 3a shall be sent (no octet 3a means "presentation allowed" per
default).
Regards,
Karl
[View Less]
This material now appears as COM16-D305.
> -----Original Message-----
> From: Sakae OKUBO [SMTP:okubo@GITI.OR.JP]
> Sent: Monday, May 10, 1999 10:11 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Input from ATMF
>
> Dear Q.12-14/16 experts,
>
> A possible input to the SG16 meeting from ATMF
>
> "Gateway for H.323 Media Transport Over ATM" AF-SAA-0124.000, Final
> Ballot,
> May, 1999
>
> has been placed at the ftp site:
>
> ftp://…
[View More]standard.pictel.com/avc-site/9905_San/af-saa-0124.000.zip
> or
> http://standard.pictel.com/ftp/avc-site/9905_San/af-saa-0124.000.zip
>
> Please note that its type of the document (liaison, Nortel Delayed
> Contribution, TD, ...) is not known yet.
>
> Best regards,
>
> Sakae OKUBO (Mr.)
> ***********************************************************
> Waseda Research Center
> Telecommunications Advancement Organization of Japan (TAO)
> 5th Floor, Nishi-Waseda Bldg.
> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
> 169-0051 Japan
> Tel: +81 3 5286 3830
> Fax: +81 3 5287 7287
> e-mail: okubo(a)giti.or.jp
> ***********************************************************
[View Less]
Dear Q.12-14/16 experts,
A possible input to the SG16 meeting from ATMF
"Gateway for H.323 Media Transport Over ATM" AF-SAA-0124.000, Final Ballot,
May, 1999
has been placed at the ftp site:
ftp://standard.pictel.com/avc-site/9905_San/af-saa-0124.000.zip
or
http://standard.pictel.com/ftp/avc-site/9905_San/af-saa-0124.000.zip
Please note that its type of the document (liaison, Nortel Delayed
Contribution, TD, ...) is not known yet.
Best regards,
Sakae OKUBO (Mr.)
***********************…
[View More]************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
[View Less]
This message is to aid discussion of the structure of the
LocalTerminationDescriptor and RemoteTerminationDescriptor components of the
Add, Modify, and Move commands. In our protocol draft, the local and remote
termination descriptors actually represent two directions of transmission,
inwards to the MG and outwards from the MG respectively. Each requires its
own media description.
The two proposals for media description are to use structures modelled on
the media description components of …
[View More]SDP (RFC 2327), or to use structures
modelled on the H.245 OpenLogicalChannel (OLC) and OpenLogicalChannelAck
commands. This note shows details of each structure.
I start with the SDP structure. The complete set of headers in the media
description is described in RFC 2327 as follows. Asterisks denote optional
elements.
Media description
m=<media> <port> <transport> <fmt list>
i=* (media title)
c=* (connection information - optional if included at session-level)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)
Here is an example of an SDP media description:
m=video 49232 RTP/AVP 98
i=Pictures at an exhibition
c=IN IP4 134.134.157.81
a=rtpmap:98 L16/16000/2
Now here is the structure of a media description which would be consistent
with the H.245 OLC and OLCAck structures. I say "consistent with" because
it is structured like the OLC and OLCAck, but contains only the information
which would result from their exchange. Indentation is used to show data
structures within data structures. The tags used are the names of the
various components in their ASN.1 description. The comments following the
"--" show the mapping to SDP.
H245_channel_descriptor=
logicalChannelNumber= <value in range 1...65535> -- unique to H.245
dataType= <medium (implicit tag)> <codec description> -- m= and a=
headers
h2250LogicalChannelParameters=
<non-standardized parameters> -- SDP X- extensions
<RTP or T.120 sessionID> -- not settable by SDP
<associated sessionID> -- (for lip synch) -- not settable by SDP
<mediaChannel> -- transport address -- c= header
<mediaGuaranteedDelivery> -- TRUE for TCP transport -- m= header
<mediaControlChannel> -- RTCP address/port (optional) -- implicit in
SDP
<mediaControlGuaranteedDelivery> -- TRUE for TCP transport -- not in
SDP
<silenceSuppression> -- not in SDP -- part of RTP profile?
<destination> -- designates final destination if connection is to MCU
but
stream is intended for a particular terminal --
not in SDP
<RTP payload type> -- m= header, possibly augmented by a= header(s)
<transportCapability> -- RSVP or ATM QOS parameters -- not in SDP
-- lower-layer transport -- c= header
<redundancy encoding specification> -- m= header
<source> -- designates originating terminal if working through MCU
-- not in SDP
<logicalChannelDependency> -- which channel this one depends on
if hierarchical encoding used -- implicit in SDP by order of port
numbers in m= header
separateStack=
-- address for setting up ATM connection -- c= header
-- alternatively, information for joining T.120 conference -- a=
header?
encryptionSynch=
-- key for media encoding -- k= header
One small step in the discussion ...
Tom Taylor
E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor)
Tel.: +1 613 736 0961 (ESN 396-1490)
FAX: same number by prior arrangement (manual answer).
[View Less]
At 10:43 AM 5/7/99 +0200, Karl.Klaghofer(a)ICN.SIEMENS.DE wrote:
>Glen and others,
>
>It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling
>party number IE. It has led to interoperability problems with the SCN in
>the past (where octet 3a is used) !
I agree. I might be okay in an enterprise environment, but in a Service
Provider environment the lack of Octet 3a makes it impossible to support
the CLIP/CLIR service as defined in Q.951 in an standard manner.
&…
[View More]gt;Now, it is time to fix this error as discussed in the Monterey Rapporteuts
>meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via
>Implementors Guide !). There may be procucts already planning on that
>announced correction.
>
>An endpoint B - not supporting octet 3a of Calling Party Number Information
>element - should treat this situation as a "non-mandatory information
>element content error". The reaction to such an type of error shall be:
>* Take actions on the SETUP received and on all the information
>elements that are recognized and have valid contents; i.e. ignore only the
>Calling party Number IE
>* A STATUS may optionally be returned with Cause #100.
>
>Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0,
>since H.225.0 is so much based on the Q.931).
>
>So, if such an endpoint B receives an octet 3a in Calling party Number set
>to "presentation allowed", all that happens is that the Number would not be
>displayed at B.
The only problem I see is the optional STATUS message. Implementations
using the STATUS message option will generate unnecessary traffic. In a
low-volume environment, this shouldn't be too bad.
>But for the really critical case where the octet 3a is received by such an
>endpoint B being set to "presentation restrictet", we have even the behavier
>we intend, namely NOT to display the number to the endpoint B (since the
>whole IE should be ignored anyway).
In the case of interoperating with a v1/v2 implementation that doesn't
recognize Octet 3a, the receiver will drop the Information Element and,
worst case, send a STATUS message. Thus, worst case is that the Calling
Party Number will not be available to the receiving endpoint. This seems
to be a sufficient failsafe to me.
Since the SCN Gateway must implement policy anyway, it could also have a
policy to act on Octet 3a differently (e.g., drop the Calling Party Number
if "presentation restricted" is encoded or the digits aren't available and
pass it on without Octet 3a otherwise.).
>A miscoded optional Information element should never lead to a clearing of
>the call !
>
>Regards,
>Karl
>------------------------------------------------
>Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1
>Hofmannstr. 51, D-81359 Munich, Germany
>Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
>e-mail: karl.klaghofer(a)icn.siemens.de
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Glen Freundlich [SMTP:ggf@lucent.com]
>> Gesendet am: Donnerstag, 6. Mai 1999 22:11
>> An: ITU-SG16(a)mailbag.cps.intel.com
>> Betreff: caller ID and implementer's guide
>>
>> At the Monterey meeting we discussed the possibility of an addition to
>> the Implementer's Guide to support caller ID features (APC-1527).
>> H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party
>> Number IE (and also specifies that the octet 3 extension bit shall be
>> set to 1). The proposal calls for removing the restriction through the
>> Implementer's Guide. (See also the meeting report in APC-1554b.)
>>
>> Fixing this brings up the possibility of interoperability problems with
>> existing products. Please respond if you think this change will be a
>> problem. You can respond to me individually, rather than to the entire
>> list, if you prefer.
>>
>> Thanks,
>> Glen
>>
>>
>> --
>> Glen Freundlich ggf(a)lucent.com
>> Lucent Technologies office: +1 303 538 2899
>> 11900 N. Pecos fax: +1 303 538 3907
>> Westminster, Colorado 80234 USA
--------------------------------------------------
Chip Sharp voice: +1 (919) 851-2085
Cisco Systems Consulting Eng. - Telco
Reality - Love it or Leave it.
--------------------------------------------------
[View Less]
