![]() | |
| |||||||||||||||
| |||||||||||||||
| Tags: busy, calls, coming, detect, extn, qsig, tone, trunk |
![]() |
| | LinkBack | Thread Tools | Display Modes |
| | #1 (permalink) | ||||||||
| Junior Member ![]() dmad is alive and well
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: 5 ![]() | 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 ![]() dmad is alive and well
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 ![]() dmad is alive and well
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... | ||||||||
| | |
| | #8 (permalink) | ||||||||
| Junior Member ![]() dmad is alive and well
Location: London Rep Power: 0 ![]() | Its somekind of soft PBX running using some kind of off-the-shelf QSIG cards....i think the trace is being pushed upon me to find on the NEC because their engineer feels the PBX is rejecting the call etc... | ||||||||
| | |
![]() |
| 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 |
| Trunk to Trunk connection woes... | Hi-Tech | Meridian Systems | 4 | September 16th, 2009 07:00 PM |
| How to check External Transfer? | dominick | Meridian Systems | 11 | September 16th, 2009 11:43 AM |
| Returning busy tone instead of reorder on trunk route | telecom116 | Meridian Systems | 6 | March 31st, 2005 05:46 PM |
| Am I being hacked? | cliffzig | Meridian Systems | 8 | September 10th, 2004 09:51 AM |
| CHage UNR for all sets | Meridian Systems | 7 | March 2nd, 2004 01:59 PM | |