| | #1 (permalink) | ||||||||
| Junior Member
Location: London Rep Power: 0 ![]() | Calls coming in over QSIG trunk don't detect busy tone when extn is busy.... 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!!?? | ||||||||
| | |
| | #2 (permalink) | ||||||||
| Junior Member
Rep Power: 4 ![]() | NEC extension is busy, the trace on the other PBX says "idle" and the connection gets NU tone (solid tone). Trace? Q931 trace? The messaging for ISDN is handled over the D-Channel. When the NEC extension is busy. It will return a message stating that. Its upto the originating office to return the Busy Tone. Mextera | ||||||||
| | |
| | #3 (permalink) | ||||||||
| Junior Member
Location: London Rep Power: 0 ![]() | Hi matey Well, we've been looking into the trace commands but not having much joy finding anything referencing them...namely CMF62>07D CMF62>1Sense CMF62>3:0 CMF62>4:0 CMF62>0:19 We haven't yet tried these because as the manual jumps from F5 to F7, we can't be sure what they do!? Probably our next home is a Q931 trend, but we have access to one on a very limited basis... thanks! | ||||||||
| | |
| | #5 (permalink) | ||||||||
| Junior Member
Location: London Rep Power: 0 ![]() | Hi Yeah, normal calls over thw QSIG are fine. What this 'second pbx' does is it has virtual extensions on it which the end user is able to define a first, second and third choice of where to re-route calls. So say 3001 is a virtual on the NEC PABX which sends all traffic straight to a matching virtual on PBX#2. An auto attendant when answers the call and attempts to put the caller through to a 'real' NEC extensions (say 2001). If 2001 doesn't answer, the the call is retrieved back to PBX#2 and it will attempt the second choice, perhaps a mobile which is also directed back to the QSIG and out over PSTN (ISDN30). What fails is when say 2001 is busy, the PBX#2 cannot detect it has been given a busy tone and the call hangs. What we're not sure of at the moment is whether the problem is different if the 2nd destination is either another NEC extension or an external call...Can't see why that would make a difference when, to me the problem is with the two PBXs agreeing on what signifies a busy tone... | ||||||||
| | |
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | |
| |
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| How to check External Transfer? | dominick | Meridian Systems | 10 | 03-21-2006 03:53 AM |
| Returning busy tone instead of reorder on trunk route | telecom116 | Meridian Systems | 6 | 03-31-2005 04:46 PM |
| Am I being hacked? | cliffzig | Meridian Systems | 8 | 09-10-2004 08:51 AM |
| CHage UNR for all sets | Meridian Systems | 7 | 03-02-2004 12:59 PM | |
| Trunk to Trunk connection woes... | Hi-Tech | Meridian Systems | 2 | 02-05-2003 07:25 PM |