This James Carlson article is cross-posted to comp.dcom.isdn to reach
those naysayers that hang out in comp.dcom.isdn and comp.dcom.modems.
Yes. I personally used a 5399 to make an ISDN voice bearer call intoQuote:> > My previous job was with the former Bay Networks, and I was a
> > technical lead on the 5399 and 8000RAC projects. Both of these server
> > systems support V.90 *AND* sync PPP using DOSBS, and both will
> > automatically detect the type of call and serve it appropriately. (In
> > addition, of course, to standard V.120 and V.110.)
> And this means that bidirectional 64 kbit/s is available by calling an
> ISP's V.90 number with an ISDN *voice* bearer capability, right?
an 8000RAC over a Teleos switch and ran 64Kbps synchronous PPP over
it. No big deal.
Right. Note that this is the Bay Remote Access equipment, which isQuote:> Thanks for your evidence. In another post you claim that the Bay ISDN
> equipment will lock onto 64 kbit/s or 56 kbit/s rate adaption PPP
> automatically if the caller is sending such as initiating HDLC flags,
> and only if this fails will the Bay ISDN equipment attempt V.90
> negotiation for other callers, right? Regardless of incoming bearer
> capability, right?
really the old Xylogics Annex server. I have no idea whether the Bay
Nautica routers (which are really the old Scorpion Clams) or the Bay
AN routers (which are the old Wellfleet routers) have the same
capabilities. These are all DIFFERENT products that came from
In the 5399 and the 8000RAC, this works by running multiple passes
over the %wan section of the config.annex file. In the first pass,
the initial ISDN IEs are decoded into a set of filters that select the
first matching SPB (session parameter block). This SPB can direct the
call -- regardless of "how" it matched the call -- into any possible
service (64K sync PPP, 56K sync PPP, 64K V.120, 56K V.120, 64K V.75,
56K V.75, true async V.110, or V.90 digital modems) or into a protocol
sniffer which will listen for 56/64 PPP and V.120. (I think they
extended it for at least V.75 after I left.) If the sniffer is
selected ("call_action detect"), then the SPBs are again scanned with
the new information.
Note that there is NO direct connection between detected call type --
ISDN voice bearer, for instance -- and the termination type -- 64K
sync PPP, for instance. These can be configured any way you'd like.
The default, though, if you're too lazy to write a %wan section is
that voice calls go to the modems, and other calls get autodetected.
What you're asking for looks something like this (the syntax might be
a little rusty; I left Bay over a year ago):
That will simple ignore the bearer capability, and sniff out the
protocol instead. If you'd like the deliberately use bearer, you
might do this:
set speed 64000
It is true that some equipment has artificial limitations on the wayQuote:> I'll look up that book you wrote, but I would actually prefer someone
> posting their 64 kbit/s DOSBS/DOVBS success with Bay equipment. As yet,
> I have NEVER seen ANYONE in the US claim, here or in comp.dcom.isdn,
> that they have equipment that supports bidirectional 64K on *voice*
> bearercap answered connections, only a bunch of diversionary (and pure
> bunk) arguments as to why this non-V.110-like bidirectional capability
> is only limited to intra-switch connections, so it isn't worth the
bearer capability is used. I seem to remember running into those
problems on the Ascend Pipeline 50, where it would insist on 56K when
voice was seen, but my memory could be faulty there.
No. We run the protocols *SEPARATE* from the bearer capabilities. IfQuote:> When you say "in addition to standard V.120 and V.110" I assume this
> means for a *data* bearer capablity that relies on ISDN's High Layer
> Compatibility information to choose either V.120 or V.110, which is
> nothing more than plain old ISDN standards compliance, right?
the IE says just "64K data," we can choose to run V.120 based on
called number, calling number, or sniffing. The capabilities are so
unreliable around the world that this usually has to be configured by
had. Most of the ISPs I dealt with simply established separate
dial-in numbers for each service and used the called_num feature to
separate the calls in the 5399. (Crude and a little expensive because
of the number appearances, but it always works.)
Certainly true. That's why our SPBs work the way they do. The ISDNQuote:> If so, I
> don't think HLC information is currently able to be passed in much of
> the US SS7 signaling networks (I could be wrong about this, I haven't
> looked at any new ISUP code for a while).
networks suck, and most switches completely snarf the IEs. (Many will
outright reject the calls if there are oddball IEs in them!)
Well, that's a darned shame. The Livingston Portmaster was aQuote:> If you mean that V.120 or
> V.110 is autodetected on answered *data* bearercaps, too, well, good for
> you, you have been able to use this thread to inform telecom
> professionals how much better Bay ISP equipment is than any other US
> vendor (Lucent Portmasters autodetect but forget to check for
> bidrectional 64
> kbit/s ;-)
reasonable device, but I can't say that I did a lot of competitive
analysis on them.
Easy. Yes, without a doubt, it will do it, as long as the switchesQuote:> Will you please confirm and testify, here in comp.dcom.telecom.tech,
> that without a doubt, Bay equipment at two different sites is able to
> support a bidirectional 64 kbit/s DOSBS/DOVBS?
aren't intentionally scrubbing the data. I've used this myself and it
Does that work any better for you?
IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132
Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp