Cisco Cisco Unified MeetingPlace Audio Server Maintenance Manual
6-2
Cisco MeetingPlace Audio Server 5.2 Customer Engineering Guide (for Cisco MeetingPlace 8112)
OL-
Chapter 6 Troubleshooting
System does not answer
E1 ports that do not answer
For E1 ports that do not answer, follow this procedure:
Step 1
Verify that the span is up using the “spanstat” command. See the
for
more information. If the E1 trunks show no alarms:
a.
The PBX/Telco routing may not be set up correctly or trunks may be in a lockout state.
b.
Use “spanstat <span number> -all” to verify that calls are being presented to the system. The call
state changes when a caller dials into the system.
state changes when a caller dials into the system.
A proper incoming call should follow the sequence:
–
“ds” (incoming call) => “ii” (call active) => “..” (port idle)
A proper outgoing call should follow the sequence:
–
“sd” (outgoing call) => “oo” (call active) => “..” (port idle)
Note
If a “ds” => “..” or “sd” => “..” transition occurs quickly, this indicates that the near-end or
far-end, respectively, is rejecting the call. Verify that the port is active on the MeetingPlace
side (near-end) and the ISDN service is activated on the far-end. Contact the Cisco TAC for
information on determining the ISDN cause code for the call rejection.
far-end, respectively, is rejecting the call. Verify that the port is active on the MeetingPlace
side (near-end) and the ISDN service is activated on the far-end. Contact the Cisco TAC for
information on determining the ISDN cause code for the call rejection.
Note
If a port stays in any of these states for more than ten seconds, this indicates a possible
protocol problem where one side is not clearing down the telephone call all of the way (“do”,
“di”, “od”, “id”). If this is the case, contact the Cisco TAC to determine if ISDN messages
are being lost.
protocol problem where one side is not clearing down the telephone call all of the way (“do”,
“di”, “od”, “id”). If this is the case, contact the Cisco TAC to determine if ISDN messages
are being lost.
Step 2
Look for errors on the span using the “spanstat -s” command.
Step 3
Verify correct cabling (frequently reversed):
pin 1 — MP Receive (tip), pin 2 — MP Receive (ring)
pin 4 — MP Send (tip), pin 5 — MP Send (ring)
pin 4 — MP Send (tip), pin 5 — MP Send (ring)
Step 4
Verify the configuration with the “e1span” command. See the
for more
information.
Step 5
Check the framing and coding using the “protparm” and “e1span” commands. See the
for more information.
Check the port group’s protocol table
Verify that the port group for any troubled port references the correct protocol table for the ISDN
protocol being interfaced to.
protocol being interfaced to.
Step 1
At the tech$ prompt, type
port
appears.