DMS100 vs. 5ESS
Andrew H. Kauffman
Sounds like BS to me. All Ordering Codes have a version for Lucent 5ESS,
Nortel, and Siemens CO's. I do not know what is special about S1, other
than it is a slight modification to IOC S. IOC S is a standard ordering
code, but does not have ACO. Depending on what equipment you are getting,
you may want to look at using IOC U (aka EZ-1). This will support ACO, and
adds call forwarding features that are useful with voice mail. EZ-1 will
work with 95 % of the ISDN equipment on the market.
As for which CO to use, I prefer the Lucent. Nortel has yet to deliver a
fully compliant version of their ISDN software for the DMS 100. In my
opinion, until they do so, we should shun them and publicly challenge then
to step up to the plate and fix their switch. My biggest complaint,
support for up to 8 SPIDS (the standard). This will allow you to connect
up to 8 logical devices to your line at once. A good example is a work at
home type. 1 SPID for your ISDN telephone (no analog single line junk at
work please), 1 SPID for the analog port supporting your fax (probably on
your Super NT-1 with battery back up from ATI), 1 SPID for your old modem
to use, 2 SPIDS for your ISDN router (simply the fastest way to get to the
Internet, and it can support multiple PC's using the same connection), and
maybe 2 SPIDs for your Videoconference System (these are now sub-$1000 and
will show up in many work at home offices this year). What if you need a
TA for occasional use. We have used up all the SPIDs. Northern has
promised this functionality for 3 years in a row, and failed to deliver.
--
Andrew Kauffman
------------------------------------------
AHK & Associates, Inc.
Consultants in Advanced Telecommunications
a...@ahk.com www.ahk.com
------------------------------------------
bob <uctr...@ultranet.com> wrote in article
<356eb588....@vnntp.ma.ultranet.com>...
> Do I care if I end up on a DMS100 and not a 5ESS ?
>
> I asked BA for an s1 package. ( I plan to do 56/112k
> DOV access ) They originally had me slated for a
> 5ESS, but then said I needed a DMS100 when I specified
> the S1 package (data and voice on both, ACO, callerid,
> etc.) , claiming it doesn't work on a 5ESS. So,
> do I really care what switch I end up on ?
>
>
> I know a little about ISDN, but precious little about
> switches.
>
> thanks,
>
>
> bob
>
> remove NOSPAM to email - unless I already did it for you
>
Sam C. Nicholson !!
bob wrote:
>
> Do I care if I end up on a DMS100 and not a 5ESS ?
>
You should. Unless you are not really interested in
taking advantage of all that ISDN has to offer.
> I asked BA for an s1 package. ( I plan to do 56/112k
> DOV access ) They originally had me slated for a
> 5ESS, but then said I needed a DMS100 when I specified
> the S1 package (data and voice on both, ACO, callerid,
> etc.) , claiming it doesn't work on a 5ESS. So,
> do I really care what switch I end up on ?
>
Hmm, Yet another case of BellA******* hot being able to
tell the difference between, well, you know...
When I made my initial order, they didn't even have an
ordering code other than "Generic voice+data."
Just order what you can from the bozos in order to
stay on the 5E, and then call BA ISDN repair and request
a change to what you want.
I am connected to the Woodacres 5ESS in the 320 NXX.
I have caller ID (Standard with ISDN), ACO, the works.
Actually I have: TermType=C MAXTERM=6 and CACH/EKTS
on all three of my SPIDs.
I use a combination of analog devices hung off some
AlphaTelecom gear, a Lodestar ISDN Telephone, and
a Sun Sparc 10. All works like a charm (except when
BellA******* makes an unplanned DB change and re-sets
my third SPID ):
However, I have been told many times that what I have
is "Impossible." The idiots at 800-204-7332 are geared
only to setup ISDN for BSpro or Ascend P25 type gear.
Now the folks at BellA ISDN repair really know their stuff.
So if you can, get them on the line when you are setting up
your service.
-sam
Sam C. Nicholson !!
bob wrote:
>
> On Thu, 28 May 1998 12:28:14 -0400, "Sam C. Nicholson !!"
> <sc...@webrelay.net> wrote:
>
> >> I asked BA for an s1 package. ( I plan to do 56/112k
> >> do I really care what switch I end up on ?
Hmmm. frotzed attribution. I merely quoted the person who said that.
> The plot thickens ! I found a page at 3-com (sorry for the long URL)
> that discusses switch types and the lan modem:
>
> http://www.remoteaccess.3com.com/support/docs/lanmodem/documentation/3C892/ISDNorder.html
> Then at the end of the page they say that Simultaneous V & D can
> be provided on a Lucent 5ESS NI1 or a Siemens EWSD - but are
> specifically *not* available on a Nortel DMS-100.
Anyway, Good bit of searching. Yet another reason to *not* want to
be on a DMS-100.
>
> So, if you're still with me (apologies for the length here), are
> they right ? If they put me on a DMS100 does ACO only work on
> one physical number ?
There are folks here who know far more about it, but I believe that
those are separate issues. But they may well blur in that if you are
on a "data" call (Hey! it's *all* data on ISDN), then the DMS may well
not Offer you an Additional Call. The Nortel folk figured out already
what you want to do with that ISDN line, and a call offering while you
are on a data call might just not be what you wanted :).
> And do they have the ability to move me to
> another switch even if I ask ie., won't all the switches in
> a CO normally be the same type -
If they need to put you on another switch to provide service, that
would *most* likely at another CO. Switches are tres expensive and
require a fair bit of support. In the event that the telco needed
more than one switch at a CO ( and really a CO is defined as the locus
of a switch, so what I just said may not make sense ), they would
be the same.
> or could they actually be
> smart enough to have several switch types available in a CO?
Don't rightly know if I'd call that smart. Would be expensive as
all get out. I'd just pick the most feature-full switch and use
that. If I needed another one, I'd get one just like the first,
and not need to hire/contract any more techs.
If I really needed to terminate a CP at a different type of switch,
I'd back haul.
Which, by the by, is exactly what BellSouth did in Tennessee when
they agreed to make ISDN universally available. In areas where they
figured that the demand was low, they dropped in a few clear channel
muxes, and allocated some T carriers to handle the load.
They continued to do that when an area's demand grew, but the local
switch wouldn't work with the ISDN feature sets they had announced.
Given my experiences with BellA****** (yep 6 of 'em, you guess :),
Id be very surprised if they didn't charge you for the back haul
if there was any reason to claim that you wanted something not
available at the local CO. And that could well be ISDN itself.
As well, it could be some feature not supported. And I'd be careful
what I asked of them in the ordering process. I'd hate to hear
that you got charged for back-haul when you were just curious about
the features locally.
I'd be very explicit that I wanted whatever was available locally!
> (They just added ISDN to local CO's last year at the NYNEX/BA
> CO's here in the burb's if that matters)
>
How utterly futuristic of them.
David Lesher
uctr...@ultranet.com (bob) writes:
>Do I care if I end up on a DMS100 and not a 5ESS ?
Yes; if you ever need more than 2 SPIDs....
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Jeffrey Rhodes
David Lesher wrote:
>
> uctr...@ultranet.com (bob) writes:
>
> >Do I care if I end up on a DMS100 and not a 5ESS ?
>
> Yes; if you ever need more than 2 SPIDs....
>
... on the same BRI, which I believe, implies that the ISDN terminal
equipment is NOT U-only, but requires an NT-1 for S/T bus devices. This
leads me to ponder that separate provisioning packages may be required
for some U-only devices, versus the provisioning that is afforded to
more versatile S/T bus devices, although some U-only devices may be able
to exist within a subset of the more versatile provisioning that S/T
devices require :-)
regards, jcr
Al Varney
In article <3572E4...@attws.com>,
Jeffrey -- so far as I can tell, the switch has no means of knowing
if you have a U-only device that supports multiple TEIs, several S/T-bus
devices supporting only one TEI each or some S/T-bus devices each supporting
several TEIs. A U-only device can obviously handle multiple SPIDs, as
can S/T-bus devices. I can't think of any remote test that would distinguish
a real NT-1 from a U-only device. Provisioning certainly doesn't care.
I won't mention the other option -- S/T-lines directly to the switch
(no U-interface). Common on PBXs and extensively used on our 10,000+
ISDN line Centrex campus, served by a portion of a local 5ESS-2000 switch.
Al Varney
Rhodes
Thanks for the information, Al.
I have noticed that so many of the US ISDN U-only devices are limited to
support 2 SPIDs, and that's usually because they want to support DOVBS and
need two billable Directory Numbers to create 112kbps M-PPP connections. It
helps to match provisioning characteristics to the intended devices,
admittedly the line card software will remain the same. So I presume the TA
vendors have conformed to "Package A" or "Package U" and I have noticed
inconsistencies when I "mix and match" various TAs with the BRI lines that I
have access to. (I do come by alot of TAs ;-)
So ISDN in the USA remains kindof a "majic" artwork always in progress,
128kbps ISDN DOVBS always in the future. Maybe the future will bill people
for their use within big bundles of usage minutes?
I don't want to put you on the spot, but what about that claim I saw that
the DMS100 in NOT a non-blocking switch. Like the Alcatel switches, Lucent
switches are non-blocking, and can only be made to be blocking by adding
blocking line units. Or is that *feature* limited to the DMS200? Maybe you
don't know and someone else knows?
Regards, Jeffrey
Al Varney wrote in message <6l3nms$r...@ssbunews.ih.lucent.com>...
Fred R. Goldstein
In article <6l3qdg$a...@bgtnsc02.worldnet.att.net>,
jeffrey...@worldnet.att.net says...
>
>I have noticed that so many of the US ISDN U-only devices are limited to
>support 2 SPIDs, and that's usually because they want to support DOVBS and
>need two billable Directory Numbers to create 112kbps M-PPP connections.
You're drinking early again, Jeffie. DOVBS has NOTHING to do with it.
US gear uses two SPIDs because NI-1 allows a switch to limit a SPID to a single
B channel at a time, so the only way to activate two B channels is to have two
SPIDs. For ANY bearer capability. For ANY use of the Audio bearer capability.
It's that way because the DMS-100 works that way, and NI-1 is basically a
cleaned-up DMS Custom, warts and all. A 5E or EWSD can do more with one SPID
but the vendors dumb down to the DMS level in order to have a single NI-1
flavor.
It takes real obsessive creativity to tie in the fantasy about 64k DOVBS into
this topic!
>I don't want to put you on the spot, but what about that claim I saw that
>the DMS100 in NOT a non-blocking switch. Like the Alcatel switches, Lucent
>switches are non-blocking, and can only be made to be blocking by adding
>blocking line units. Or is that *feature* limited to the DMS200? Maybe you
>don't know and someone else knows?
A DMS-x00 has a non-blocking Network in the middle. A DMS-100 (or 100/200, or
500) has a Line Concentration Module, which is typically blocking, for BRI and
analog lines. Trunk ports are non-blocking. Other than the lousy BRI and sort
of mediocre analog ports, the DMS is a fine switch. Plenty of inbound PRI
capacity, something the 5E was desperately short of until very recently.
--
Fred R. Goldstein k1io fgoldstein"at"bbn.com
GTE Internetworking - BBN Technologies, Cambridge MA USA +1 617 873 3850
Opinions are mine alone; sharing requires permission.
Al Varney
In article <6l3qdg$a...@bgtnsc02.worldnet.att.net>,
Rhodes <jeffrey...@worldnet.att.net> wrote:
>I have noticed that so many of the US ISDN U-only devices are limited to
>support 2 SPIDs, and that's usually because they want to support DOVBS and
>need two billable Directory Numbers to create 112kbps M-PPP connections.
It's my impression that '2 SPID support' is to match NI-1 implementation
MINIMUMS supported by the DMS100, which is all that's tariffed in some places.
I don't believe NI-1 spec LIMITS an implementation to 2 SPIDs, nor does it
require 2 SPIDs for a single device using both B channels. It is also my
impression that DOVBS is an after-thought in some TA designs, and certainly
didn't DRIVE the need for or limit of 2 SPIDs. One could imagine a U-only
device acting as a PBX, using 8 SPIDs and "pretending" to be 8 devices,
one per extension. Then the switch would screen/bill/route calls based
on the originating device. That's a pretty limiting implementation, but
it could be IMAGINED.
For a typical U-interface TA with a single data interface and one or two
POTS ports, what would more than 2 SPIDs offer?
>I don't want to put you on the spot, but what about that claim I saw that
>the DMS100 in NOT a non-blocking switch. Like the Alcatel switches, Lucent
>switches are non-blocking, and can only be made to be blocking by adding
>blocking line units. Or is that *feature* limited to the DMS200? Maybe you
>don't know and someone else knows?
Well, I don't know and I'm positive someone else does, but you'd probably
ask someone @nortel.com. From public information, it's hard to tell if
switches are POSSIBLY non-blocking or ALWAYS non-blocking -- that is, is
it possible to engineer a given switch as non-blocking or is it only offered
in a non-blocking arrangement. I don't know of any Lucent CO switch that is
ALWAYS non-blocking, such that every line can always call any idle line,
even if all other lines are already connected. (I believe 2:1 concentration
ratio is the lowest offered -- before ISPs, these were typically used only in
heavy business/Centrex areas.) I'm discounting the option of leaving some
line terminals un-assigned -- that kludge would allow you to claim even the
1A ESS(tm) switch could be engineered as non-blocking!
Even for tandem switches, there are usually blocking (cheaper)
configurations available. (I'm not sure what is magical about a non-blocking
CO arrangement, anyway. If all but 2 lines are busy, what are the odds that
one idle line will want to call the other? On the other hand, offering
non-blocking ACCESS to the CO is reasonable when traffic demands it. Forcing
rate-payers to pay for every line to be non-blocking is probably something
the PUCs wouldn't permit, unless TELCO can show no cheaper alternatives exist.)
The 1A ESS switch is a good example of how blocking is influenced by
internal architecture. The larger the switch, the greater the probability
of internal fabric blocking on line-to-line calls (the internal ports on
a given line network unit have to be inter-connected to more and more other
line network units, and there are thus fewer and fewer paths available
between any two line units.) At some point (around 80K lines, as I recall),
the solution is to remove ALL the internal paths between line network units
and switch every line-to-line call through back-to-back trunks. This allows
the number of line-network-unit to trunk-network-unit paths to be increased,
and drops internal blocking probabilities back to the range of a small switch.
(Back-to-back trunks aren't as expensive as they might sound. Even direct
line-to-line calls on the 1A ESS switch require use of a unit similar to a
trunk circuit to supply battery/ground and perform supervision. The
back-to-back trunk circuits are actually cheaper -- but tie up some added
trunk network paths.)
Al Varney - just my opinion
Fred R. Goldstein
In article <3576b451....@vnntp.ma.ultranet.com>, no...@stopthespam.com
says...
>...starting to worry, I actually understood most of that ! When I
>start to understand the 64K ODVBS issue I'll really know I've been
>in this ng too long :-)
>
>Are you saying that the 5E or EWSD does the multi-channels per
>spid *now*, or that the capability is there and they shut it
>of in common usage ? Reason I ask is that 3-com infers that
>if one channel/directory number is in use and a call comes to the
>same directory number that a 5E or EWSD will forward it to the
>other channel, almost like a hunt group. They refer to it
>as provisioning for "Simultaneous Video and Data" and specifically
>note that it will work on a 5E or EWSD but *not* a DMS100.
It is possible, now, so far as I know, to configure an EWSD or 5E with more
than one call at a time on a SPID. So yes, it may well be that some features
fail on a DMS for that reason. On the other hand I've always preferred "AT&T
Custom" on the 5E, which doesn't have the intentional brain damage of NI-1.
What your telco will actually do depends on their own policy.
Robert Blackshaw
Al Varney wrote:
>
> In article <6l3qdg$a...@bgtnsc02.worldnet.att.net>,
> Rhodes <jeffrey...@worldnet.att.net> wrote:
> >I have noticed that so many of the US ISDN U-only devices are limited to
> >support 2 SPIDs, and that's usually because they want to support DOVBS and
> >need two billable Directory Numbers to create 112kbps M-PPP connections.
>
> It's my impression that '2 SPID support' is to match NI-1 implementation
> MINIMUMS supported by the DMS100, which is all that's tariffed in some places.
> I don't believe NI-1 spec LIMITS an implementation to 2 SPIDs, nor does it
> require 2 SPIDs for a single device using both B channels. It is also my
> impression that DOVBS is an after-thought in some TA designs, and certainly
> didn't DRIVE the need for or limit of 2 SPIDs. One could imagine a U-only
> device acting as a PBX, using 8 SPIDs and "pretending" to be 8 devices,
> one per extension. Then the switch would screen/bill/route calls based
> on the originating device. That's a pretty limiting implementation, but
> it could be IMAGINED.
>
"The terminal shall (R) provide the capability for the user to enter and
store one
unique Service Profile IDentification (SPID) for each TEI that it
supports."
HTH
Bob
--
"Since when was genius found respectable?"
E. B. Browning
Jeffrey Rhodes
Robert Blackshaw wrote:
>
> Al Varney wrote:
> >
> > In article <6l3qdg$a...@bgtnsc02.worldnet.att.net>,
> > Rhodes <jeffrey...@worldnet.att.net> wrote:
> > >I have noticed that so many of the US ISDN U-only devices are limited to
> > >support 2 SPIDs, and that's usually because they want to support DOVBS and
> > >need two billable Directory Numbers to create 112kbps M-PPP connections.
> >
> > It's my impression that '2 SPID support' is to match NI-1 implementation
> > MINIMUMS supported by the DMS100, which is all that's tariffed in some places.
>
> "The terminal shall (R) provide the capability for the user to enter and
> store one
> unique Service Profile IDentification (SPID) for each TEI that it
> supports."
>
> HTH
>
> Bob
Well, please elaborate. For some reason I believe that a U-only US ISDN
device using National ISDN-1 as defined by Bellcore, only requires 1
SPID in order to make a 128kbps ISDN data call. I could be wrong, but I
got the impression that many U-only devices would like to support only 1
SPID, but actually support 2 SPIDs in order to support 2-B DOVBS calling
that is only possible with a minimum of 2 SPIDs.
I could be wrong, but I believe point-to-point (as opposed to
"multi-point") Custom 5ESS BRIs do not require any SPID and yet are
still able to make 128kbps ISDN data calls, but yet are unable to make
112kbps DOVBS calls. Maybe Al will help here, too?
TIA, Jeffrey
Hank Karl
On 4 Jun 1998 18:08:24 GMT, var...@ihgp2.ih.lucent.com (Al Varney)
wrote:
> It's my impression that '2 SPID support' is to match NI-1 implementation
> MINIMUMS supported by the DMS100, which is all that's tariffed in some places.
That's pretty much what I have heard. The issue is that some areas
are served by 5ESS, some by DMS-100. And political correctness
dictates that everyone has to be made equal, so the lowest common
denominator ("2 SPID support") is used.
Also, some LECs don't want a sole-source solution, so they limit the
features they offer to those that all the major players (both of them
in the US :-) offer.
-----------------------------------
Hank Karl
Opinions mine, not my company's
to reply, remove the "imnothere" from my address
Al Varney
In article <35771E...@attws.com>,
Jeffrey Rhodes <jeffrey...@attws.com> wrote:
>Robert Blackshaw wrote:
>> Al Varney wrote:
>> > In article <6l3qdg$a...@bgtnsc02.worldnet.att.net>,
>> > Rhodes <jeffrey...@worldnet.att.net> wrote:
>> > >I have noticed that so many of the US ISDN U-only devices are limited to
>> > >support 2 SPIDs, and that's usually because they want to support DOVBS and
>> > >need two billable Directory Numbers to create 112kbps M-PPP connections.
>> >
>> > MINIMUMS supported by the DMS100, which is all that's tariffed in some places.
>> "The terminal shall (R) provide the capability for the user to enter and
>> store one
>> unique Service Profile IDentification (SPID) for each TEI that it
>> supports."
This is true, but doesn't say how many TEIs are needed for a particular
application. But let's keep going....
>Well, please elaborate. For some reason I believe that a U-only US ISDN
>device using National ISDN-1 as defined by Bellcore, only requires 1
>SPID in order to make a 128kbps ISDN data call. I could be wrong, but I
Jeffery, I know you are somehow hung up on the "U-only" thing. Let's
remove that as an issue, OK. A single-unit TA using the S/T interface
has EXACTLY the same problems/limitations as a "U-only" device. A U-only
device can support multiple TEIs, as can an S/T device.
>got the impression that many U-only devices would like to support only 1
>SPID, but actually support 2 SPIDs in order to support 2-B DOVBS calling
>that is only possible with a minimum of 2 SPIDs.
The real question is:
Can a single CPE device (U or S/T) get by with only one SPID?
Given the above Bellcore quote, this can be rephrased:
Can a single CPE device (U or S/T) get by with only one TEI?
Per Bellcore's SR-3875 National ISDN document:
2.1.2.7 Support of 2 Simultaneous Voice Calls on Different B-Channels
from a Single TEI
"On some NI-1 interfaces, terminals were required to support a separate
Terminal Endpoint Identifier (TEI) for each B channel accessed. This
restriction is relaxed with NI-2 interfaces, such that a terminal with
a single TEI may simultaneously access both B channels either for two
data calls or for one voice and one data call. However, the implementation
of some NI-2 interfaces did not allow a terminal with a single TEI to
simultaneously access both B channels for two voice calls."
So, for NI-1, any device wanting to work on all National BRI lines would
need to support 2 SPIDs, in order to activate 2 TEIs. Even to get 2 active
64K data calls. For both S/T devices or U devices.
Any device wanting to work on all National BRI lines supporting NI-2
(in other words, they ignored the NI-1 market), would need to support 2 SPIDs
only to support 2 active voice calls. This would include TAs that provided
2 POTS interfaces, as well as those desiring to support 2 active DOVBS calls
(whether to the same destination or not).
So it is possible that many U-only (and S/T-only) TAs support multiple
SPIDs because they want to work with NI-1 BRI lines. If such backward
compatibility isn't an issue, then CPE vendors will soon offer only single-
SPID devices, since NI-3 will remove this limitation:
"This enhancement expands on the NI-2 interface configurations by
allowing a terminal (initializing or non-initializing) with a single
TEI to simultaneously access both B channels for two voice calls. It
provides one more step towards interface uniformity as defined in
National ISDN-3. Using a single TEI to simultaneously access both
B channels for two voice calls allows intelligent CPE to autonomously
manage local telephone equipment, thus simplifying both the CPE and
the provisioning of the interface,. This enhancement also simplifies
integrated terminals that support both voice and analog modem
capabilities. It is also necessary for the BRI trunk application for
the CPE to operate with a single TEI."
If you want more details, I suggest buying Bellcore's documents.
You'll note that DOVBS is NOT one of the reasons offered for supporting
2 simultaneously active voice calls. While this newsgroup may believe
data access to ISPs is the sole reason for ISDN existence, there ARE other
applications....
>I could be wrong, but I believe point-to-point (as opposed to
>"multi-point") Custom 5ESS BRIs do not require any SPID and yet are
>still able to make 128kbps ISDN data calls, but yet are unable to make
>112kbps DOVBS calls. Maybe Al will help here, too?
I believe there was at one time a limit of only 1 active CSV (voice) call
per TEI. Since DOVBS uses a Voice bearer capability, and point-to-point
implies only 1 TEI, the limit existed. CSD (data) calls were not subject
to that limit. The Custom CSV limit may still exist; I haven't checked.
So far as I know, even NI-1 BRI lines on 5ESS-2000 switches do not have
the 1-voice-call limit. That's little comfort to CPE vendors, unless they
have enough market power to force replacement/upgrade of other switches.
Robert Blackshaw
Al Varney wrote:
>
<snip>
>
> If you want more details, I suggest buying Bellcore's documents.
> You'll note that DOVBS is NOT one of the reasons offered for supporting
> 2 simultaneously active voice calls. While this newsgroup may believe
> data access to ISPs is the sole reason for ISDN existence, there ARE other
> applications....
>
Jeffrey Rhodes
Al Varney wrote:
>
> In article <35771E...@attws.com>,
> Jeffrey Rhodes <jeffrey...@attws.com> wrote:
> >Robert Blackshaw wrote:
> >> Al Varney wrote:
> >> > In article <6l3qdg$a...@bgtnsc02.worldnet.att.net>,
> >> > Rhodes <jeffrey...@worldnet.att.net> wrote:
> >> > >I have noticed that so many of the US ISDN U-only devices are limited to
...bad choice of wording...I mean to say "are dependent on" not "are
limited to"
> >> > >support 2 SPIDs, and that's usually because they want to support DOVBS and
> >> > >need two billable Directory Numbers to create 112kbps M-PPP connections.
> >> >
> >> > It's my impression that '2 SPID support' is to match NI-1 implementation
> >> > MINIMUMS supported by the DMS100, which is all that's tariffed in some places.
> >...
>
> >I could be wrong, but I believe point-to-point (as opposed to
> >"multi-point") Custom 5ESS BRIs do not require any SPID and yet are
> >still able to make 128kbps ISDN data calls, but yet are unable to make
> >112kbps DOVBS calls. Maybe Al will help here, too?
>
> I believe there was at one time a limit of only 1 active CSV (voice) call
> per TEI. Since DOVBS uses a Voice bearer capability, and point-to-point
> implies only 1 TEI, the limit existed. CSD (data) calls were not subject
> to that limit. The Custom CSV limit may still exist; I haven't checked.
> So far as I know, even NI-1 BRI lines on 5ESS-2000 switches do not have
> the 1-voice-call limit. That's little comfort to CPE vendors, unless they
> have enough market power to force replacement/upgrade of other switches.
>
> Al Varney - just my opinion
Thanks to both Al and Robert, I see the information that clearly relates
to the thread's subject. I must confess I am dassled by both of you
guys' ability to elucidate what I was getting at in my previous posting.
Some people would rather ridicule, I regard your efforts as genuinely
enhancing to all here in c.d.i.
As to my allusions and dispersions on U-only devices, I must confess
that I am presuming that most US U-only devices whose vendors do not
support S/T interfaces, have taken short cuts, made possible by assuming
that two or more SPIDs will be available. This is pure speculation on my
part, but this remains an artifact as a result of experimenting with
many TAs and ISDN routers, with many combinations of 5ESS BRI "packages"
provisioned by US WEST National ISDN-1 and GTE-NW 5ESS Custom ISDN. But
I find it curious that a Bitsurfer Pro needs one kind of provisioning
package for the feature set I want, while a ZyXEL Prestige 100 needs
another provisioning package FOR THE SAME FEATURE SET! I know, I am
SPOILT because I have so many 5ESSes to choose from out here in WA. But
I think TA vendors would do well to develop software for Bellcore's NI
standard as the vanilla flavor while putting their best work into 5E
Custom ISDN, which clearly can offer the most functionality of
neopolitan flavor ;-)
So in my mind, US ISDN devices would be improved by offering more
functionality with LESS SPIDs, not more SPIDs. Yes, it is possible to
have up to eight SPIDs per U-only device, but this can lead to numbering
shortages and more area code splits, yuck. I guess we'll see what the
future brings, more SPIDs because more is better, or less SPIDs because
no SPIDs are needed in the first place, and NI-2 and NI-3 have come
along only to correct the NI-1 dependence on multiple SPIDs!
Regards, Jeffrey
Dan Lanciani
In article <6l9h48$o...@ssbunews.ih.lucent.com>, var...@ihgp2.ih.lucent.com (Al Varney) writes:
[extremely useful details snipped]
| While this newsgroup may believe
| data access to ISPs is the sole reason for ISDN existence, there ARE other
| applications....
As someone who has always been interested in those other applications (in
particular, being able to string a series of desk phones on an ISDN line
for ordinary residential voice calls), I have a slightly more abstract
SPID-related question. I may have a little trouble expressing the question
well, so bear with me. Assuming you have enough SPIDs to satisfy the
previously discussed constraints for a single device to manipulate two
B channels in any way that one could desire (i.e., 2 SPIDs for compatibility
with any known system), exactly what functionality is gained from additional
SPIDs? Since additional SPIDs can be hard to get and/or incur additional
monthly charges, they seem at first glance to act mainly as an impediment
to adding devices to the line. But is there more to it than that?
Here's another way of looking at my question. Let's say I built a box
that has a U interface on one side to talk to the CO and on the other
side either provides an S/T interface (to connect to multiple local
devices) or even a "reverse" U interface (to support an external NT1).
Now, my box is _not_ an NT1. Think of it as a PBX-in-a-box. To the CO
it looks like a single TEI. To the local bus is looks like a CO, supporting
as many SPIDs as needed. Ignoring the cost/complexity of such a box, is
there any functionality that it could not provide to the local devices
that a direct CO connection with more SPIDs could support?
Dan Lanciani
ddl@danlan.*com
Janice McLaughlin
I have some NT1's that draw their own power from
pin's 7&8 of an RJ45 on the "U" interface. (And of course
if they're not powered, they don't work). I'm wondering
if these things are useful anywhere in the real world. I know
that my local PacBell lines don't supply it and only bring out
the 2 data lines, but I thought it might be possible
another provider brought them out.
Anyone know? This isn't an ordering option is it?
Thanks!
Janice McLaughlin
David Lesher
Janice McLaughlin <ja...@more.com> writes:
>I have some NT1's that draw their own power from
>pin's 7&8 of an RJ45 on the "U" interface. (And of course
>if they're not powered, they don't work). I'm wondering
>if these things are useful anywhere in the real world. I know
>that my local PacBell lines don't supply it and only bring out
>the 2 data lines, but I thought it might be possible
>another provider brought them out.
This is common. You use a cute little adapter to connect the local
48vdc supply to those pins. Then the power travels along with the
TX and RX of the S/T bus to each phone.
Laurence V. Marks
In <01bd8a3e$302cf4e0$1200...@ank.ahk.com>, "Andrew H. Kauffman" <ne...@ahk.com> writes:
>
>As for which CO to use, I prefer the Lucent. Nortel has yet to deliver a
>fully compliant version of their ISDN software for the DMS 100. In my
>opinion, until they do so, we should shun them and publicly challenge then
>to step up to the plate and fix their switch. My biggest complaint,
>support for up to 8 SPIDS (the standard). This will allow you to connect
>up to 8 logical devices to your line at once. A good example is a work at
>home type. 1 SPID for your ISDN telephone (no analog single line junk at
>work please), 1 SPID for the analog port supporting your fax (probably on
>your Super NT-1 with battery back up from ATI), 1 SPID for your old modem
>to use, 2 SPIDS for your ISDN router (simply the fastest way to get to the
>Internet, and it can support multiple PC's using the same connection), and
>maybe 2 SPIDs for your Videoconference System (these are now sub-$1000 and
>will show up in many work at home offices this year). What if you need a
>TA for occasional use. We have used up all the SPIDs. Northern has
>promised this functionality for 3 years in a row, and failed to deliver.
>--
excellent example of using them. I could easily do that, as I have the house
wired with S/T passive bus.
But I don't recall NT promising 8 SPIDs prior to this year. As I recall, late
last year they said it would be included in NA-009 third quarter this year. I
am looking forward to it, and hoping that Bellsouth puts it on my switch as
soon as it's proved stable.
Laurence V. Marks
IBM Corp. - Research Triangle Park, NC
Laurence V. Marks
In <227...@news.IPSWITCH>, ddl@danlan.*com (Dan Lanciani) writes:
>
>Here's another way of looking at my question. Let's say I built a box
>that has a U interface on one side to talk to the CO and on the other
>side either provides an S/T interface (to connect to multiple local
>devices) or even a "reverse" U interface (to support an external NT1).
>Now, my box is _not_ an NT1. Think of it as a PBX-in-a-box. To the CO
>it looks like a single TEI. To the local bus is looks like a CO, supporting
>as many SPIDs as needed. Ignoring the cost/complexity of such a box, is
>there any functionality that it could not provide to the local devices
>that a direct CO connection with more SPIDs could support?
>
perhaps ITU document I.112.