NEC IPS2000 (R11)

The NEC is connected to another PBX via a QSIG
trunk.

When the 'other PBX' puts a call to an extension on the NEC, its successful.

When the 'other PBX' puts a call through to an extension on the NEC and the NEC extension is busy, the trace on the other PBX says "idle" and the connection gets NU tone (solid tone).

If the busy extension has a call forward to something else (external or internal), it works fine.

It seems that the NEC is not properly conducting an 'understandable' busy tone to the other PBX... Shot in the dark - any ideas!!??


So I could have my first number as an extension on the switch and then tell
my plan to go to my mobile next or, if I chose, any number on the public
network
Testing shows this will work if the first number is not answered but it
fails if the first number is engaged.

Review of the logs on the Bull Call system shows that the Bull system is
getting 'idle' back even though the device is 'on hook'.

To solve this issue we need to see the logs from the NEC giving a trace of
the progress of the call and the circumstances/call events giving rise to
the Bull Call System getting 'idle' back.

In our dealings with other switches ( namely Siemens) logs and traces are
always used on 'both sides' to identify the cause of something not working
as expected and once the cause is known modifications made to remove the
cause.

Should there be anything else in the future ( either fault or development)
the ability to trace will always be necessary. Access to logs sholud,
ideally, be available remotely and across a VPN connection.