>Jon Rust <jpr@vcnet.com> wrote:
>> normal 86.94% 659/758
>> User Request - Call Circuit Closed 7.92% 60/758
>> Lost Carrier 4.22% 32/758
>> User Request - PPP Term Ack 0.40% 3/758
>
>Are these not "normal"? I thought "Call Circuit Closed" meant they hung up,
>which seems fine, and "PPP Term Ack" sounds likely to be okay too. What
>categories have you put under "normal"?
Remember to distinguish between calls that never made it, and calls that
get past authentication. Here are a couple of posts from the past that go
to some detail at explaining the two... For the Call Circuit Closed, my
take on it is that out of 100 where x+y+z=100, x is the fault of the PM3,
and y is the client modem, and z being line conditions. No idea what the
ratio is...However, customers who call up with problems maintaining
connections almost always have CCC as their termination cause. Often it is
crappy client modems, but some of those same modems did not have problems
against other brands of terminal servers... This in a one CO town...
Here are a couple of detailed explanations. There are/were others. I
suggest you search through the archives at
http://www.livingston.com/tech/archive/portmaster-users/
for more information....
Matthew Walker <mwalker@lidcam.com.au> Lidcam Technology
-----------------------------------
Call Circuit Closed is logged as the disconnect cause when the PM receives
a disconnect message from the switch while the modem in the PM believes it
is still connected.
Lost Carrier occurs when the modem in the PM decides it has lost the
connection and it then disconnects the line.
It's all about timing. If the PM modem decides it's disconnected it's a
Lost Carrier, if the remote modem decides it's disconnected it hangs up and
causes a Call Circuit Closed.
In the instance where you issue the reset mX command the serial code in the
PM does not seem to recognise this and keeps the connection up, eventually
the other modem decides it has lost the connection and hangs up the line.
The PM then receives a disconnect from the switch and logs a calll circuit
closed.
Of course not all CCC's are the fault of the PM, some will be people
turning off or unplugging modems, some may be call waiting, some may just
be due to some transient fault on the line. Some also are, the PM modem
loses connection with the remote modem and can't bring it back up for
instance.
Lost Carriers are also strange. In my experience the PortMaster logs all
calls that are never connected as Lost Carrier (which I see as correct,
although a separate cause like Failed Connect would be good IMHO). However
once the modems actually connect the PM modem seems to have a much greater
timeout value than most client modems resulting in a very low percentage of
Lost Carriers in LE-Terminate-Detail compared to CCC as the remote modem is
timing out first and dropping the line.
I hope this helps.
Regards
Matthew Walker
Matthew Walker <mailto:mwalker@lidcam.com.au> Lidcam Technology
Ph: +61 3 9865 9077 Level 5 499 St Kilda Rd
Fax: +61 3 9866 1245 Melbourne VIC 3004
<http://www.lidcam.com.au/users/matthew/> AUSTRALIA
-------------------------------------------------------
And, James Dutton (James@superbug.demon.co.uk)
on Tue, 24 Nov 1998 11:49:57 +0000
was kind enough to post this detailed response/explanation as to what
happens when on the PM3, you do a reset m# (eg. reset m10), and why this
results in a Call Circut Closed... i.e. something is initiated at the
terminal server, causes this message to appear.
-------------------------------------------------------
Hello Mike
Here is a decode of the interesting bits of your output.
#First command sent to PM3 from remote switch Requesting Disconnect
#of the ISDN channel which the modem call was on.
D0:recv COMMAND SAPI=00, TEI=00, Info: N(S)=23, N(R)=01, Poll=0
Q.931 CRV=(From Origin)30DE Message=45-DISCONNECT
08-CAUSE 90-16:Normal call clearing
#Here the PM3 is decoding a bit. By saying it received a Disconnect
request. (set debug isdn on)
Skipping: S14: Received Disconnect Normal Clearing (B1 ID:5e5b)
Skipping: S14: Sending Disconnect Request
#The PM3 now allows the disconnect.
Echoing : D0: send 00 01 02 48 08 02 84 de 4d
D0:send COMMAND SAPI=00, TEI=00, Info: N(S)=01, N(R)=24, Poll=0
Q.931 CRV=(To Origin)30DE Message=4D-RELEASE
#The remote switch ack's it.
Echoing : D0: recv 02 01 48 04 08 02 04 de 5a
D0:recv COMMAND SAPI=00, TEI=00, Info: N(S)=24, N(R)=02, Poll=0
Q.931 CRV=(From Origin)30DE Message=5A-RELEASE COMPLETE
So although you manually reset the modem. The remote ISDN switch
initiated the disconnect at the ISDN level.
What probably happened is the modems negotiated disconnect. The remote
modem hung up first. This caused an ISDN level Circuit disconnect
request originating from the remote end.
(remote is other end,local is PM3)
So the PM3 is reporting correctly. It would be nicer if the report was a
bit more useful.
E.G. Local LAPM modem disconnect, Call Circuit closed remotely.
Or. Local Administrator reset.
But this will not be a high priority as far as Lucent are concerned,
unless a lot of their customers make it so.
Lucent priorities are Reliability, Stability, Urgent/Significant
Features, Nice features.
This will be in the nice features catagory.
> Where can I find the information to debug the stuff below ?
>
> neon> show m37
> Card Type: Lucent Chipset
> State: ACTIVE
> Active Port: S14
> Transmit Rate: 31200
> Receive Rate: 26400
> Connection Type: LAPM/V42BIS
> Chars Sent: 1041998264
> Chars Received: 107155900
> Retrains: 0
> Renegotiations: 1
>
> Total Calls: 1113
> Modem Detects: 1039
> Good Connects: 1039
> neon> D1: send 00 01 01 17
> D1: recv 00 01 01 ff
> reset mD0: send 00 01 01 47
> D0: recv 00 01 01 03
> 37
> M37: Modem Resetting
> neon> D1: send 00 01 01 17
> D1: recv 00 01 01 ff
> D0: send 00 01 01 47
> D0: recv 00 01 01 03
> D0: recv 02 01 46 02 08 02 04 de 45 08 02 80 90
> D0: send 02 01 01 48
> S14: Received Disconnect Normal Clearing (B1 ID:5e5b)
> S14: Sending Disconnect Request
> D0: send 00 01 02 48 08 02 84 de 4d
> D0: recv 00 01 01 04
> D0: recv 02 01 48 04 08 02 04 de 5a
> D0: send 02 01 01 4a
> S14: Received Clear Conf (B1 ID:5e5b)
> D1: send 00 01 01 17
> D1: recv 00 01 01 ff
> D0: send 00 01 01 4b
> D0: recv 00 01 01 05
> D1: send 00 01 01 17
> D1: recv 00 01 01 ff
>
>
> This resulted in a Call Circut closed...ComOS 3.8 against a DMS100,
> PRI
---------------------------------------
Mike Tancsa (mdtancsa@sentex.net)
Sentex Communications Corp,
Waterloo, Ontario, Canada
-
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/>