| Summary: | ASTERISK-09370: SIT tones are not detected on PRI when dialing out numbers. | ||
| Reporter: | Frank Waller (explidous) | Labels: | |
| Date Opened: | 2007-05-02 16:39:51 | Date Closed: | 2011-06-07 14:03:14 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | PRIs at a customer site are operated by Quest. Instead of reporting a q931 code for disconnected number/ non routed number/ what so ever, disconnected numbers are reported by sending in- band channel alert message (08) and the B-Channel will have the tri tone and respective message, but the line never procedes to be "picked up" and stays in ringing. In some instances we had the same problem with busy! So disconnected numbers are never detected as disconnected numbers, but as no answers and are dialed over again (predictive dialing). ****** STEPS TO REPRODUCE ****** switch on pri debug Dial disconnected number from affected trunk while listening to ZapScan call place thru app_dial [will show ringing] watch d-channel messages [08 (in-band alert) received] and listen [tri tone on b-channel and announcement message] wait [ringing will stop if timeout was specified] but listen [tri tone on b-channel and announcement message continue to play for several seconds] ****** ADDITIONAL INFORMATION ****** Carrier is Quest in Denver | ||
| Comments: | By: Whit Thiele (sirwhit) 2007-05-16 10:31:21 This issue is related to 0007793 and 0002799 I haven't been able to work on it over the past couple months but still have the same issue By: Matthew Fredrickson (mattf) 2007-10-20 14:39:18 This would require some effort in making the tones be detected properly. Unless someone is going to do this, I'm going to suspend this issue for now. | ||