64 vs 56k per channel

64 vs 56k per channel

Post by Laurence V. Mar » Mon, 04 May 1998 04:00:00




[Long and accurately quoted discussion about whether the user's TA should be
able to detect and accomodate a REPORTED routing over 56 channels deleted}

Jeffrey, you've accurately quoted me, but that's NOT the situation that applies
here.  In the case you describe, there is NO path from Point A to Point B at
64K, so the call is delivered at 56K and the calling party is so-notifed.  A
simple example is just calling your POTS phone number from your ISDN TA.

That's NOT the situation here.  The situation here is that the call must be
routed from CO-A to CO-B.  Assume there are 40 trunks between A and B; 20
are 56K trunks and 20 are 64K clear trunks.  Now assume that 19 of the 20
analog trunks are PROPERLY IDENTIFIED as analg trunks, but the 20th one is
identified as a 64K trunk.  This is due to simple documentation/data entry
errors at the telco, or possible error in setting up the trunk.  Telco people
refer to this as a 'translation error.'

One time out of 40 when making the call, you get this mislabelled trunk, even
when calling with 10-digit dialing.  56K will work, 64K will not.  What Carmen
needs to do is to call the telco while one of these calls is up, and have the
call traced so they can identify the bogus path and get the translation or
trunk setup fixed.  It's possible that they could also identify the trunk with
simple knowledge of the two endpoints.  The repair center could say which
approach they prefer.

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

 
 
 

64 vs 56k per channel

Post by Laurence V. Mar » Mon, 04 May 1998 04:00:00



Quote:>The routing at any switch is easy to define for DS0 bearer requests, it
>is easy to re-map, too. In order to preserve the integrity of 64kbps

[deletetions]

Quote:

>I have been successful here in the Northwest getting this routing right
>for some CLECS and ISPs, so I know it is a tough problem to get fixed.
>ISDN is very important for secure, digital access to ISPs. I don't like
>xDSL since it seems like the twisted pair has to share a LAN feed to the
>ISP with your neighbors. 64/128kbps is better than having to settle for
>56/112kbps.

And this is the real problem in Carmen's case.  His client is hitting a bad
translation.  PacBell has had many more problems than other LECs with them over
the last few years.  The 10-digit dialing trick was merely a device to buy time
while they work on solving it.

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

 
 
 

64 vs 56k per channel

Post by Sean Donel » Wed, 06 May 1998 04:00:00



> Actually, this is an inaccurate statement; xDSL does not share a LAN
> feed to the ISP with your neighbors.  Cable modem connectivity is the
> broadcast technology that shares bandwidth among neighbors. xDSL
> provides an independent pipe that connects you to your ISP's bandwidth
> cloud.  

All the xDSL rollouts I've seen by the RBOCs, et al include delivery of
the xDSL to the CO and then through some type of shared RBOC cloud to
the ISP equipment.  For xDSL where the copper goes directly to the ISP
equipment, your statement is true.
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation
 
 
 

64 vs 56k per channel

Post by Jeffrey Rhode » Wed, 06 May 1998 04:00:00




> > Actually, this is an inaccurate statement; xDSL does not share a LAN
> > feed to the ISP with your neighbors.  Cable modem connectivity is the
> > broadcast technology that shares bandwidth among neighbors. xDSL
> > provides an independent pipe that connects you to your ISP's bandwidth
> > cloud.

> All the xDSL rollouts I've seen by the RBOCs, et al include delivery of
> the xDSL to the CO and then through some type of shared RBOC cloud to
> the ISP equipment.  For xDSL where the copper goes directly to the ISP
> equipment, your statement is true.
> --
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
>   Affiliation given for identification not representation

Thanks, Sean, it's that RBOC cloud that I am referring to. Maybe Carmen
wants to make the argument that if you can't trust your RBOC, then ISDN
digital access isn't any good, either. I want to suggest that it is alot
easier to hook up a sniffer to the RBOC cloud, which, AFAIK, does not
require a legal wiretap, than it is to drop the 64kbps of a random ISDN
caller which DOES require a legal wiretap.

To further correct Carmen, "I have been successful here in the Northwest
getting this routing right for some CLECS and ISPs," is an accurate
statement that I have posted. If Carmen believes there is nothing that
can be done, except recommend callers to drop to 56kbps, because the
ISDN standards are deliberately muddled with respect to 64kbps CSD call
routing per Robert Blackshaw, then it will be impossible for a
Californian ISP to create a 64kbps-only access number. This would be a
clear winner if users were charged a premium for 64kbps service, whether
it be CSD or CSV type callers. Presumably this number would only be
needed when main 56kbps data limited numbers are all in use and callers
to those numbers are getting busy, or by 64kbps critical service that is
worth paying extra for. If the network is unable to fail 64kbps CSD call
attempts, then the 64kbps-only number can potentially be tied up with
unsuccessful callers that are answered, but are unable to authenticate
and protocolate ;-)

Quote:> Thanks for any insights anyone might have,
> Carmen

Yeah, right.


 
 
 

64 vs 56k per channel

Post by Tyler Hoppe » Wed, 06 May 1998 04:00:00



> Thanks, Sean, it's that RBOC cloud that I am referring to. Maybe Carmen
> wants to make the argument that if you can't trust your RBOC, then ISDN
> digital access isn't any good, either. I want to suggest that it is alot
> easier to hook up a sniffer to the RBOC cloud, which, AFAIK, does not
> require a legal wiretap, than it is to drop the 64kbps of a random ISDN
> caller which DOES require a legal wiretap.

I respectfully disagree. Both RBOCs and IXCs which use my company's
equipment can access hundreds of thousands of circuits with a couple of
clicks of a mouse. Monitoring traffic over the link at that point is
child's play. They do it many times every day and it's perfectly legal
in terms of provisioning and maintenance. Yes, monitoring for any other
reason is illegal.

This was not an ad for my company. Otherwise they'd be paying my ISP
bill.

Regards.
__________________________
Tyler Hopper

"He's a High Tech Redneck"

 
 
 

64 vs 56k per channel

Post by Robert Blacksh » Wed, 06 May 1998 04:00:00


<snip>

Quote:> because the
>ISDN standards are deliberately muddled with respect to 64kbps CSD call
>routing per Robert Blackshaw.

Try reading what I write for once Jeffrey, that's not what I wrote
and you know it.

Bob

 
 
 

64 vs 56k per channel

Post by Jeffrey Rhode » Wed, 06 May 1998 04:00:00




> > Thanks, Sean, it's that RBOC cloud that I am referring to. Maybe Carmen
> > wants to make the argument that if you can't trust your RBOC, then ISDN
> > digital access isn't any good, either. I want to suggest that it is alot
> > easier to hook up a sniffer to the RBOC/ISP cloud, which, AFAIK, does not
> > require a legal wiretap, than it is to drop the random 64kbps of an ISDN
> > caller which DOES require a legal wiretap.

> I respectfully disagree. Both RBOCs and IXCs which use my company's
> equipment can access hundreds of thousands of circuits with a couple of
> clicks of a mouse. Monitoring traffic over the link at that point is
> child's play.

Thanks, Tyler. Can your company's equipment monitor the circuit to
"hear" a conversation, or determine that it is being used by two faxes,
not two analog modems, or is of purely digital content? The 64kbps DS0
data stream would have to be converted to analog, I would think.

Monitoring the embedded 64kbps data stream of a DS0 or ISDN B-channel is
not child's play and I'd be amazed if any US RBOC or IXC has this ready
at the click of a mouse. More likely it requires a tap onto the wires
that carry the 64kbps and some equipment to "drop" the DSO or B-channel,
or, requires special switch routing for FBI surveillance ordered by a
court. I think you are referring to the ability that RBOCs and IXCs have
to determine whether a circuit is in use or idle? RBOCs and IXCs do not
arbitrarily listen into phone conversations, faxes, analog modems or
digital communications. In the course of maintaining circuits, as you
note, this may occur, but it usually requires someone to physically
touch something more than a mouse.

Quote:> They do it many times every day and it's perfectly legal
> in terms of provisioning and maintenance. Yes, monitoring for any other
> reason is illegal.

Please enlighten me as to how a child can play with a mouse at your
company to monitor a phone conversation in the network. Newt wants to
know, too ;-)

regards, jcr

 
 
 

64 vs 56k per channel

Post by Floyd Davids » Thu, 07 May 1998 04:00:00




>> I respectfully disagree. Both RBOCs and IXCs which use my company's
>> equipment can access hundreds of thousands of circuits with a couple of
>> clicks of a mouse. Monitoring traffic over the link at that point is
>> child's play.
...
>to determine whether a circuit is in use or idle? RBOCs and IXCs do not
>arbitrarily listen into phone conversations, faxes, analog modems or
>digital communications. In the course of maintaining circuits, as you
>note, this may occur, but it usually requires someone to physically
>touch something more than a mouse.

>> They do it many times every day and it's perfectly legal
>> in terms of provisioning and maintenance. Yes, monitoring for any other
>> reason is illegal.

>Please enlighten me as to how a child can play with a mouse at your
>company to monitor a phone conversation in the network. Newt wants to
>know, too ;-)

The best way I know of to put such a discussion in perspective is this:

  Do NOT EVER say anything on a telephone, send anything by FAX,
  or put any data on a digital or modem circuit, that you cannot
  tolerate showing up on the front page of tomorrow's local
  newspaper.  It is not that it is likely to happen, but there is
  nothing preventing it either...

In the course of maintaining circuits, technical staff does
arbitrarily monitor any or all of the above, and for anyone with
six months experience it is indeed child's play.  For a person
with years of experience and a deviant bent of mind, it is even
worse.  Ideally that should never happen, but it does.

I have _literally_ seen a transcript of a man essentially
confessing to a * in a telephone conversation printed on
the front page of a newspaper.  He went to jail...

  Floyd

--

Ukpeagvik (Barrow, Alaska)                                        

 
 
 

64 vs 56k per channel

Post by Jeffrey Rhode » Thu, 07 May 1998 04:00:00




> >ISDN standards are deliberately muddled with respect to 64kbps CSD call
> >routing per Robert Blackshaw.

> Try reading what I write for once Jeffrey, that's not what I wrote
> and you know it.

> Bob


Quote:>  Jeffrey, there were endless arguments at the standards meetings,
> while the ISDN Recommendations were being written, about this
> very thing.

And nothing was resolved? No standardization within the standards
process?

Quote:> Data people said "Don't complete the call if you can't provide the
> QoS I ask for." Telephone people (from years of tradition) said,
> "Do your best to complete the call regardless, then let the user
> decide if the QoS is acceptable."

So which side do you agree with? Should a 64kbps data call be routed to
a POTS line per the Telephone people, so that the answering user can
decide whether the QoS is acceptable and so that the caller is charged
(toll or percall units)? That last one is a rhetorical question, the
first one is what I am interested in.

Quote:> Actual practice varies, some switches when asked for 64k clear
> and only having 56k trunks will clear the call with a cause code.

I'll go out on a limb and declare that EVERY AT&T owned and operated
switch does this, so that when all clear channel circuits are busy, an
ISDN 64kbps data user can hammer call attempts without percall, answered
call failures. Sometimes muddled routing is a result of overflow
routing, so repeated call attempts will eventually get through
succesfully.

Quote:> BTW, I know about the arguments, I was there.

> Bob

Well, at least it helped you put together the admirable effort available
at http://veda-home.com/Blackshaw/

No, I haven't read all of the chapters but I will, and a donation to the
King County Pet Licensing Agency will follow. I have to register my cat
here every year and the form has a line for donations, too. Let me
guess, you are a dog owner.

I guess what I read into your quotes above is that some networks
tolerate the conversion of an ISDN user's call attempt for Unrestricted
64K to become a request for Unrestricted 56K, (there's no such thing in
practise as Restricted 56K anymore), right? So people like Carmen and
the 64K callers to Carmen's ISP have little to argue about with their
carriers when this happens, afterall the best standards people in the
industry can't agree on the best procedure. This is what I call a
muddled routing.

There is a good solution, get a billing relationship with AT&T Accunet
(1-800-943-8288) and use 102881 prefix to casually dial a local number.
(Did you try that with your Adtran back in 1995?) When a 64K ISDN data
caller is successful with AT&T routing, yet their normal carrier gives
them anything they've got muddled routing, well, then the user can at
least ask their carrier "why aren't your circuits as good as AT&T?"
Maybe that will get some action and unmuddle the routing ;-)

Seriously, I relish your comments, even if they get on my nerves
sometimes. I wonder if Arnette Schultz from Lucent will pick up on this,
he told me he has something to do with ANSI Q931/ISUP interworking
standards. I'll try to copy him in E-mail. I'd sort of like to know what
is being considered for US ISDN Caller Name, too.

regards, jcr

 
 
 

64 vs 56k per channel

Post by Tyler Hoppe » Thu, 07 May 1998 04:00:00



> Thanks, Tyler. Can your company's equipment monitor the circuit to
> "hear" a conversation, or determine that it is being used by two faxes,
> not two analog modems, or is of purely digital content? The 64kbps DS0
> data stream would have to be converted to analog, I would think.

It can extract a DS0 thru DS1 signal from any of several access mediums
and deliver it to a protocol analyzer. Hmmm, was that an ATM PIN that
just went by?

Quote:

> Monitoring the embedded 64kbps data stream of a DS0 or ISDN B-channel is
> not child's play and I'd be amazed if any US RBOC or IXC has this ready
> at the click of a mouse. More likely it requires a tap onto the wires
> that carry the 64kbps and some equipment to "drop" the DSO or B-channel,

Consider yourself amazed because most US RBOCs and several IXCs in fact
do. Sorry, I won't give customer names. Perhaps some of them may speak
up. The way data services are provisioned, they automatically have test
access (i.e.. Digital Crossconnect Systems). Many/most RBOCs and IXCs
also recognize the need for metallic test access and provide such on
loops. Not all use ours. Other vendors which come to mind are Wiltron,
Lucent, and TTC.

Quote:> or, requires special switch routing for FBI surveillance ordered by a
> court. I think you are referring to the ability that RBOCs and IXCs have
> to determine whether a circuit is in use or idle? RBOCs and IXCs do not
> arbitrarily listen into phone conversations, faxes, analog modems or
> digital communications. In the course of maintaining circuits, as you
> note, this may occur, but it usually requires someone to physically
> touch something more than a mouse.

No, I'm not referring to idle/busy verification. I can from my desk gain
remote access to a physical circuit. I then deliver it to a test set
which will have a physical connection to the circuit. I can tell the
test set to deliver it to a protocol analyzer. I can let the expert
level of the analyzer do it's thing. If I'm a guru, I can analyze to the
bit level. I can look at Frame Relay and ATM and Q.931, ....

The system interface is GUI. Yes, you do have to type in a username and
password and then enter a circuit number. From there it is, in fact,
mouse clicks.

Quote:> Please enlighten me as to how a child can play with a mouse at your
> company to monitor a phone conversation in the network. Newt wants to
> know, too ;-)

I didn't say at my company, I said with my company's equipment and
system. And o.k. I will tell you. Let's pretend you're that child. Enter
your username and password. Enter circuit ID. Click on test button. When
GUI circuit diagram comes up, click on the location you want to test
from. System knows it's a voice circuit because of the CLCI and it knows
your monitor call back number. It has the Remote Test Unit (RTU) call
that number and voila, you're sitting on top of the circuit. Does
someone using the line hear you come in? Depends on the access medium,
but not likely. Assuming you are a legitimate tester, you may then split
the circuit and perform VOMCAP and transmission tests. If you're not,
well ...........

Get it? Do you think I'm making this stuff up? Rest assured that most
communications lines in the US have test access on them and can be
remotely accessed by tens of thousands telco employees using some sort
of computerized test or surveillance system. That's surveillance in
telco terms, not FBI terms.

Regards.
__________________________
Tyler Hopper

"He's a High Tech Redneck"

 
 
 

64 vs 56k per channel

Post by Thomas Dekki » Thu, 07 May 1998 04:00:00



>> I respectfully disagree. Both RBOCs and IXCs which use my company's
>> equipment can access hundreds of thousands of circuits with a couple of
>> clicks of a mouse. Monitoring traffic over the link at that point is
>> child's play.

>Thanks, Tyler. Can your company's equipment monitor the circuit to
>"hear" a conversation, or determine that it is being used by two faxes,
>not two analog modems, or is of purely digital content? The 64kbps DS0
>data stream would have to be converted to analog, I would think.

ISDN B channel, DS0, POTS, whatever, if it's "audio" data, then it's PCM
point to point.  In case of a POTS line, it's PCM between the channel banks.

The SAGE 930A is a great device for decoding PCM data and playing the audio
equivalent through it's speaker.  It will duplex both sides of the
conversation as well, if you wish.

As far as FAXes, modems and other "digital" analog devices go, it's rather
simple to do DSP analysis on the raw data and then decipher the resulting
waveforms (how convenient for the protocols to be so well documented by
EIA/TIA!)

Quote:>Monitoring the embedded 64kbps data stream of a DS0 or ISDN B-channel is
>not child's play and I'd be amazed if any US RBOC or IXC has this ready
>at the click of a mouse. More likely it requires a tap onto the wires
>that carry the 64kbps and some equipment to "drop" the DSO or B-channel,
>or, requires special switch routing for FBI surveillance ordered by a
>court. I think you are referring to the ability that RBOCs and IXCs have
>to determine whether a circuit is in use or idle? RBOCs and IXCs do not
>arbitrarily listen into phone conversations, faxes, analog modems or
>digital communications. In the course of maintaining circuits, as you
>note, this may occur, but it usually requires someone to physically
>touch something more than a mouse.

Actually, most telco switch techs prefer CLI commands to using a mouse.

The better digital DACS systems can do non-intrusive testing of any DS0
running through a switching center that can tell if there's valid PCM data
or not.

If it's valid PCM data, a simple command can route either or both sides of
the conversation through an audio monitor.  If it's not valid PCM data, it
is very trivial to sample the session and analyze the data traffic later, or
heck, just loop in a HP INET box or other capable protocol analyzer and
watch the data in real-time:

<<<<<V.35 PPP_Frame IP TCP Orig:192.178.1.2:23 Dest:192.168.1.1:1094 OK
50 61 73 73 77 6f 72 64   3a                          Password:

Quote:>>>>>V.35 PPP_Frame IP TCP Orig:192.168.1.1:1094 Dest: 192.168.1.2:23 OK

70 65 6e 63 69 6c 0d 0a                               pencil..

Who needs ssh?

Quote:>> They do it many times every day and it's perfectly legal
>> in terms of provisioning and maintenance. Yes, monitoring for any other
>> reason is illegal.

>Please enlighten me as to how a child can play with a mouse at your
>company to monitor a phone conversation in the network. Newt wants to
>know, too ;-)

Check out a TellLabs or TTC equipment catalog and be scared: Big Brother
*is* watching you, for fun and profit.

TdC

 
 
 

64 vs 56k per channel

Post by Jeffrey Rhode » Thu, 07 May 1998 04:00:00



> As far as FAXes, modems and other "digital" analog devices go, it's rather
> simple to do DSP analysis on the raw data and then decipher the resulting
> waveforms (how convenient for the protocols to be so well documented by
> EIA/TIA!)

Thanks, Thomas, I was looking for that information. Not only is it
intuitively obvious, it is known to the prior art.

regards, jcr