Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by Jeffrey Rhode » Tue, 29 Dec 1998 04:00:00



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.


comp.dcom.telecom.tech:

Quote:> > 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?

Yes.  I personally used a 5399 to make an ISDN voice bearer call into
an 8000RAC over a Teleos switch and ran 64Kbps synchronous PPP over
it.  No big deal.

Quote:> 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?

Right.  Note that this is the Bay Remote Access equipment, which is
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
different acquisitions.

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):

        begin_session sniff
        call_action detect
        end_session

        begin_session run
        call_action any
        end_session

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:

        begin_session mycall
        called_num 1234
        bearer voice
        call_action syn
        set speed 64000
        end_session

Quote:> 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
> bother.

It is true that some equipment has artificial limitations on the way
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.

Quote:> 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?

No.  We run the protocols *SEPARATE* from the bearer capabilities.  If
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.)

Quote:> 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).

Certainly true.  That's why our SPBs work the way they do.  The ISDN
networks suck, and most switches completely snarf the IEs.  (Many will
outright reject the calls if there are oddball IEs in them!)

Quote:> 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 ;-)

Well, that's a darned shame.  The Livingston Portmaster was a
reasonable device, but I can't say that I did a lot of competitive
analysis on them.

Quote:> 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?

Easy.  Yes, without a doubt, it will do it, as long as the switches
aren't intentionally scrubbing the data.  I've used this myself and it
works nicely.

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

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by Laurence V. Mar » Mon, 04 Jan 1999 04:00:00



>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.


>comp.dcom.telecom.tech:

[lines deleted]

Quote:>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.

[more deleted]

Great stuff.  No one ever said it couldn't be done, just that they didn't
care to do it.

BTW, I really think he means X.75, not V.75, Jeffrey.

Laurence V. Marks
IBM Corp. - Research Triangle Park, NC

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by Rhode » Mon, 04 Jan 1999 04:00:00




writes:
>>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.


>>comp.dcom.telecom.tech:
>[lines deleted]

>>In the 5399 and the 8000RAC, this works by running multiple passes
....
>[more deleted]

>Great stuff.  No one ever said it couldn't be done, just that they didn't
>care to do it.

>BTW, I really think he means X.75, not V.75, Jeffrey.

>Laurence V. Marks
>IBM Corp. - Research Triangle Park, NC

Hi Laurence,

Yes, James Carlson acknowledged this mistake in another post. I do not
consider you a naysayser, Laurence, though many of your posts seem to echo
the conventional wisdom:

"bidirectional 64K is not much better than existing V.90 28/50K, so it is
not worth the effort to improve upon plain old US ISDN conventionally
limited bi-56K DOV".

Since a bidirectional probe of "initiating HDLC flags" can discern when
digital impairments exist on an otherwise presumed clear channel connection
between digital ends, in order to revert to plain old US ISDN conventional
DOV, it makes sense for the European ITU V.91 standard to adopt the
bidirectional probe algorithm I posted under the thread "V90/91 .."
yesterday, since it allows fast resolution of clear channel capability for
European bi-64K, yet dynamically reverts to bi-56K in the portions of the US
where digital limitations may still be a problem, even on a percall basis.

I know that you know this is possible, since you told me about some patent,
circa 1994, that claims to be able to use a much more complicated algorithm.
You also know that I have been posting about this for five years in these
newsgroups. I do believe my algorithm is better and will actually work, even
on long distance connections and A/mu-law conversion.

Of course, asynchronous devices can get asynchronous conversion to
synchronous operation simply by removing at the start/stop bits at any
DTE/DCE boundary and then replacing (if needed) start and stop bits around
every octet at the farend's DCE/DTE boundary! This is the main point I tried
to establish with James Carlson. He claimed, then later corrected himself,
that async conversion in not even possible without some modem protocol like
V.42 or V.110 or V.120. This is simply not true. All that is needed is to
pump PPP packets down asynchronously at a bitrate much greater than the
synchronous bit rate, buffer these packets for stop/start bit removal, then
send the packet on an HDLC aligned synchronous bitrate such as bi-64K.

So, in summary, bi-64K operation on synchronous, no protocol, circuits, can
deliver PPP encapsulated IP to improve upon bi-56K DOV, but only when clear
channels exist in the underlying synchronous circuits, and the Rhodesian
bidirectional probe algorithm that I finally got right (I think) on Jan 1,
1999, will be able to help digital callers to V.90/91 servers to revert to
bi-56K ONLY WHEN APPROPRIATE for digitally impaired synchronous circuits !!!

Has you conventional wisdom been swayed to help promote Rhodesian probing
for bi-56/64K synchronous operation?

Regards, Jeffrey

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by JD » Thu, 07 Jan 1999 04:00:00


Someone mentioned the Ascend Pipeline 50 having problems with 64k DOSBS? ..
what about the PIpeline 25? I just ordered ISDN provisioned for Voice only..
that's why I ask.. and plan to buy a usued Pipeline 25...

Thanks,
JD



>writes:
>>>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.


>>>comp.dcom.telecom.tech:
>>[lines deleted]

>>>In the 5399 and the 8000RAC, this works by running multiple passes
>....
>>[more deleted]

>>Great stuff.  No one ever said it couldn't be done, just that they didn't
>>care to do it.

>>BTW, I really think he means X.75, not V.75, Jeffrey.

>>Laurence V. Marks
>>IBM Corp. - Research Triangle Park, NC

>Hi Laurence,

>Yes, James Carlson acknowledged this mistake in another post. I do not
>consider you a naysayser, Laurence, though many of your posts seem to echo
>the conventional wisdom:

>"bidirectional 64K is not much better than existing V.90 28/50K, so it is
>not worth the effort to improve upon plain old US ISDN conventionally
>limited bi-56K DOV".

>Since a bidirectional probe of "initiating HDLC flags" can discern when
>digital impairments exist on an otherwise presumed clear channel connection
>between digital ends, in order to revert to plain old US ISDN conventional
>DOV, it makes sense for the European ITU V.91 standard to adopt the
>bidirectional probe algorithm I posted under the thread "V90/91 .."
>yesterday, since it allows fast resolution of clear channel capability for
>European bi-64K, yet dynamically reverts to bi-56K in the portions of the
US
>where digital limitations may still be a problem, even on a percall basis.

>I know that you know this is possible, since you told me about some patent,
>circa 1994, that claims to be able to use a much more complicated
algorithm.
>You also know that I have been posting about this for five years in these
>newsgroups. I do believe my algorithm is better and will actually work,
even
>on long distance connections and A/mu-law conversion.

>Of course, asynchronous devices can get asynchronous conversion to
>synchronous operation simply by removing at the start/stop bits at any
>DTE/DCE boundary and then replacing (if needed) start and stop bits around
>every octet at the farend's DCE/DTE boundary! This is the main point I
tried
>to establish with James Carlson. He claimed, then later corrected himself,
>that async conversion in not even possible without some modem protocol like
>V.42 or V.110 or V.120. This is simply not true. All that is needed is to
>pump PPP packets down asynchronously at a bitrate much greater than the
>synchronous bit rate, buffer these packets for stop/start bit removal, then
>send the packet on an HDLC aligned synchronous bitrate such as bi-64K.

>So, in summary, bi-64K operation on synchronous, no protocol, circuits, can
>deliver PPP encapsulated IP to improve upon bi-56K DOV, but only when clear
>channels exist in the underlying synchronous circuits, and the Rhodesian
>bidirectional probe algorithm that I finally got right (I think) on Jan 1,
>1999, will be able to help digital callers to V.90/91 servers to revert to
>bi-56K ONLY WHEN APPROPRIATE for digitally impaired synchronous circuits
!!!

>Has you conventional wisdom been swayed to help promote Rhodesian probing
>for bi-56/64K synchronous operation?

>Regards, Jeffrey

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by James Carlso » Thu, 07 Jan 1999 04:00:00



> Someone mentioned the Ascend Pipeline 50 having problems with 64k DOSBS? ..
> what about the PIpeline 25? I just ordered ISDN provisioned for Voice only..
> that's why I ask.. and plan to buy a usued Pipeline 25...

I just remember seeing a hard-coded decision in *one* of the Ascend
products that an inbound call over a voice bearer on a T1 line was
automatically 56K call.  I might be mistaken (that work-breakdown-
structure-like menu system was really hard to use), and it was a long
time ago.  I've been up to my armpits in SONET/SDH for a year and a
half, so it's hard to remember silly things like that.

--

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

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by JD » Thu, 07 Jan 1999 04:00:00


=) .. Yah.. Suppose it will still beat the hell out of my buggy USR modem..
still be nice to have full 128k with DOV.. anyone else have any information?

Thanks,
JD


>I just remember seeing a hard-coded decision in *one* of the Ascend
>products that an inbound call over a voice bearer on a T1 line was
>automatically 56K call.  I might be mistaken (that work-breakdown-
>structure-like menu system was really hard to use), and it was a long
>time ago.  I've been up to my armpits in SONET/SDH for a year and a
>half, so it's hard to remember silly things like that.

>--

>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

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by Aaron Leona » Fri, 08 Jan 1999 04:00:00


Well, *we* support 64k DOV, FWIW.

Aaron

---

~ =) .. Yah.. Suppose it will still beat the hell out of my buggy USR modem..
~ still be nice to have full 128k with DOV.. anyone else have any information?
~
~ Thanks,
~ JD
~
~ >
~ >I just remember seeing a hard-coded decision in *one* of the Ascend
~ >products that an inbound call over a voice bearer on a T1 line was
~ >automatically 56K call.  I might be mistaken (that work-breakdown-
~ >structure-like menu system was really hard to use), and it was a long
~ >time ago.  I've been up to my armpits in SONET/SDH for a year and a
~ >half, so it's hard to remember silly things like that.
~ >
~ >--

~ >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

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by JD » Fri, 08 Jan 1999 04:00:00


Who's *WE*?

=)


>Well, *we* support 64k DOV, FWIW.

>Aaron

>---


>~ =) .. Yah.. Suppose it will still beat the hell out of my buggy USR
modem..
>~ still be nice to have full 128k with DOV.. anyone else have any
information?
>~
>~ Thanks,
>~ JD
>~

>~ >
>~ >I just remember seeing a hard-coded decision in *one* of the Ascend
>~ >products that an inbound call over a voice bearer on a T1 line was
>~ >automatically 56K call.  I might be mistaken (that work-breakdown-
>~ >structure-like menu system was really hard to use), and it was a long
>~ >time ago.  I've been up to my armpits in SONET/SDH for a year and a
>~ >half, so it's hard to remember silly things like that.
>~ >
>~ >--

>~ >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

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by Aaron Leona » Fri, 08 Jan 1999 04:00:00


Sorry, "we" = Cisco in that context.  Specifically the IOS
routers such as the 800 and above.  I'm not sure offhand
about the 700s.

To be a little less terse ... we are willing to treat an
incoming or outgoing DOV call as 64k or 56k, your choice.
That doesn't mean of course that we guarantee that you'll
be able to GET 64k (or 56k, for that matter.)  

My personal view is that, if you place a call asking the
network for voice circuit, you only *deserve* to get a voice-grade
circuit - if you should happen to  get better than that, that's gravy.

Aaron

---

~ Who's *WE*?
~
~ =)
~
~ >Well, *we* support 64k DOV, FWIW.
~ >
~ >Aaron
~ >
~ >---
~ >

~ >
~ >~ =) .. Yah.. Suppose it will still beat the hell out of my buggy USR
~ modem..
~ >~ still be nice to have full 128k with DOV.. anyone else have any
~ information?
~ >~
~ >~ Thanks,
~ >~ JD
~ >~

~ >~ >
~ >~ >I just remember seeing a hard-coded decision in *one* of the Ascend
~ >~ >products that an inbound call over a voice bearer on a T1 line was
~ >~ >automatically 56K call.  I might be mistaken (that work-breakdown-
~ >~ >structure-like menu system was really hard to use), and it was a long
~ >~ >time ago.  I've been up to my armpits in SONET/SDH for a year and a
~ >~ >half, so it's hard to remember silly things like that.
~ >~ >
~ >~ >--

~ >~ >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
~
~

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by JD » Fri, 08 Jan 1999 04:00:00


Mmmm gravy.. too bad I'm too poor to afford new Cisco stuff.. used Ascend
for me.. wheee.. =)

JD


>Sorry, "we" = Cisco in that context.  Specifically the IOS
>routers such as the 800 and above.  I'm not sure offhand
>about the 700s.

>To be a little less terse ... we are willing to treat an
>incoming or outgoing DOV call as 64k or 56k, your choice.
>That doesn't mean of course that we guarantee that you'll
>be able to GET 64k (or 56k, for that matter.)

>My personal view is that, if you place a call asking the
>network for voice circuit, you only *deserve* to get a voice-grade
>circuit - if you should happen to  get better than that, that's gravy.

>Aaron

>---

>~ Who's *WE*?
>~
>~ =)
>~

>~ >Well, *we* support 64k DOV, FWIW.
>~ >
>~ >Aaron
>~ >
>~ >---
>~ >

>~ >
>~ >~ =) .. Yah.. Suppose it will still beat the hell out of my buggy USR
>~ modem..
>~ >~ still be nice to have full 128k with DOV.. anyone else have any
>~ information?
>~ >~
>~ >~ Thanks,
>~ >~ JD
>~ >~



Quote:>~ >~ >
>~ >~ >I just remember seeing a hard-coded decision in *one* of the Ascend
>~ >~ >products that an inbound call over a voice bearer on a T1 line was
>~ >~ >automatically 56K call.  I might be mistaken (that work-breakdown-
>~ >~ >structure-like menu system was really hard to use), and it was a long
>~ >~ >time ago.  I've been up to my armpits in SONET/SDH for a year and a
>~ >~ >half, so it's hard to remember silly things like that.
>~ >~ >
>~ >~ >--
>~ >~ >James Carlson, Consulting S/W Engineer


Quote:>~ >~ >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

- Show quoted text -

Quote:>~
>~

 
 
 

Bi-64 kbit/s for ISDN DOVBS callers to V.90 RAS

Post by Rhode » Tue, 12 Jan 1999 04:00:00


Why did you attempt to limit your exposure on this thread, i.e. by only
posting within c.d.i.? A genie lent me a Cisco 766 this afternoon. It will
only originate 56K DOV, so I am stuck configuring it to call my genie
friend, to pick up an IP off the genie's Cisco something better than 760
series router, using 56K limited DOV and regular old 64K DOD. Thanks for the
Aaron Leonard suggestion ...
regards, jcr


writes:

>ATTENTION JEFFREY RHODES!!
>ATTENTION JEFFREY RHODES!!
>ATTENTION JEFFREY RHODES!!
>ATTENTION JEFFREY RHODES!!

>Apparently the 800 Series Cisco routers have supported 64K DOV for some
>time.  Please get one and report results.  If it is indeed so capable,
>please make it a point to post that every time the question comes up.

>>Sorry, "we" = Cisco in that context.  Specifically the IOS
>>routers such as the 800 and above.  I'm not sure offhand
>>about the 700s.

>>To be a little less terse ... we are willing to treat an
>>incoming or outgoing DOV call as 64k or 56k, your choice.
>>That doesn't mean of course that we guarantee that you'll
>>be able to GET 64k (or 56k, for that matter.)

>>My personal view is that, if you place a call asking the
>>network for voice circuit, you only *deserve* to get a voice-grade
>>circuit - if you should happen to  get better than that, that's gravy.

>Laurence V. Marks
>IBM Corp. - Research Triangle Park, NC