> I have a description of the problem that clearly indicates it is the
> customer doing the dialing. I only used the words "sometimes" and
> "occasionally", but didn't clearly state that it happens once in a
> period of several days. I have a thousand calls a day coming in on
> this PM3. Have you seen what "set console, set debug isdn on, set
> debug 0x51" generates?
If the PM3 in question is running some beta of 3.8, you can use the PPP
Decoder. This is most useful if you have a trunk or two that have their
own numbers and that are not part of the main group. Otherwise, even a
few screens of debugging output is not impossible to search through, and
you could even write a quick script to pluck out just the port info you
needed.
> You seem to have mixed two different problems. This is not a DOSBS
> problem. This is an MLPPP problem. Seperately, there is a DOSBS
> problem with a different TA. Do you have customers with Courier
> I-Modems that are able to connect using DOSBS to a (56k-equipped) PM3?
> I doubt it. I believe the I-Modem is at fault; my gripe there is
> Livingston using outdated compatability information and refusing to
> update the test or (heaven forbid) try to find a workaround.
A Courier I-Modem customer helped us debug the PM3s when we first got them
running and I -think- he was able to make a dual channel DOSBS call. I
can look into that though.
I have run into Sportster 128K users that have had problems making any
type of dual channel call, to a PM3 or to a PM2. One eventually got
things working properly, and I am not sure what happened to the other
user.
> It is not, however, unreasonable to expect them to understand the
> question. Nor is it unreasonable to expect them to be able to
> communicate effectively. "I need more information could you enter."?
> This does not fill me with a lot of confidence that, should I capture
> a few days' worth of debugging and send it to them, they'll be able to
> find what is needed.
I've called Cisco for support and more than once have gotten someone whose
English was not quite easy to understand, but knew exactly how to fix my
problem. Knowledge about the product matters more to me than dulcet
tones. The Lucent tech's request, while terse, was comprehensible.
> It probably is, but those are not the reasons I'm "smacking around
> support". I'm smacking around support because of the strong aura of
> incompetence they radiate. I'm very tired of explaining things three
> or four times, with a day's lag between question and answer.
You can call technical support about not incredibly critical problems.
Do not complain about having to wait for a callback AND email lag -- pick
whichever one is more tolerable. We had a problem a few months ago with a
user's 3Com TA. When Lucent called back (same day), we got the user on
the phone, made a conference call, and Lucent watched in real time.
Problem solved in about 15 minutes -- a Bell Atlantic tandem problem,
which was caught by the ISDN debugging.
In terms of dual-channel ISDN customers with Adtran equipment, I do not
know of any customers here that are using them. We have not run into many
ISDN connection problems that were PM related, even with some pretty
obscure CPE.
-- Scott M. Drassinower scottd@cloud9.net Cloud 9 Consulting, Inc. White Plains, NY +1 914 696-4000 http://www.cloud9.net- To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>