[Home]

Summary:ASTERISK-18420: [regression] Inbound ISDN Overlap dial breaks with Asterisk Version >= 1.8.4.0
Reporter:Thomas Z. (zircon)Labels:
Date Opened:2011-09-05 13:22:16Date Closed:2011-09-13 16:03:01
Priority:CriticalRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:1.8.4 1.8.5.0 1.8.6.0 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-20049 Double PROGRESS message when overlap dialing is enabled
Environment:Linux Debian 4.0, libpri-1.4.12, dahdi-linux-complete-2.5.0+2.5.0Attachments:( 0) jira_asterisk_18420_v1.8_test.patch
( 1) pri_debug_not_working.txt
( 2) pri_debug_working.txt
Description:We are using a Digium PCI E1 interface card connected to a german network.
Overlap dialing is configured in chan_dahdi.conf with overlapdial=yes.
The incoming dial plan is configured with 2 digits extensions.

AEL is something like this:
{noformat}
context incoming {
   _0! => {
// Do Something
   };

  _ZX! => {
// Do Something
  };

  _99XXX! => {
// Do Something
  };
};
{noformat}

If you now dialing from outside with a ISDN connected telephone with sequenced dialing (first hook off then dial the digits) then we found the following problem:

*+Problem:+*
After the first digit of the extension the telephone hears a ring signal.
If you now press more digits they are transferred via DTMF and are not received by asterisk. After 3 seconds the signal is switched to "number is not valid".

*+Expected:+*
After the first digit of the extension nothing is signaled because the number (extension) is not complete. If a another digit is pressed the ring signal appears and the extension rings. This behavior is working until version 1.8.3.3. With 1.8.4 it is not working any more.

*+Effected Asterisk versions:+*

# 1.8.2.3 OK
# 1.8.3.3 OK
# 1.8.4.0 Failures
# 1.8.4.4 Failures
# 1.8.5.0 Failures
# 1.8.6.0 Failures

Comments:By: Richard Mudgett (rmudgett) 2011-09-06 12:08:40.934-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!


By: Thomas Z. (zircon) 2011-09-07 06:52:05.586-0500

I updated the description of the bug.
By: Thomas Z. (zircon) 2011-09-07 07:03:11.499-0500

In the file *pri_debug_working.txt*:
The callee dials first '998' and receiveing later the rest of the extension '01'.

In *pro_debug_not_working.txt*: The first dialed extension is received '2' an the 2nd digit is lost.
By: Richard Mudgett (rmudgett) 2011-09-07 16:05:54.588-0500

The [^pri_debug_not_working.txt] trace looks normal.  The missing digits do not seem to be transmitted to Asterisk so Asterisk cannot add them to the dialed extension.

[^jira_asterisk_18420_v1.8_test.patch] comments out sending the PROGRESS message to indicate that dialtone is present.

If this patch works then your equipment is misinterpreting the meaning of the PROGRESS message.  From your description of hearing ringing it seems like your equipment is interpreting the PROGRESS message as an ALERTING message.  The PROGRESS message is *not* supposed to change the call state.
By: Thomas Z. (zircon) 2011-09-08 01:26:52.309-0500

Hi Richard,

I applied your patch [^jira_asterisk_18420_v1.8_test.patch] to Asterisk 1.8.5.0 and now the Overlap Dialing is working again.

Before I opened the bug I talked with a technician of our telephone network provider. He debugged the E1 connection and said that the problem is on the asterisk side and not on the netwok side. Just for your information.

Thank you very much for this patch!

Best wishes
Thomas

By: Leif Madsen (lmadsen) 2011-09-12 12:06:22.082-0500

Assigned to Richard for feedback. Not sure where this issue should go. Is this patch something that should be merged into Asterisk, or is it just showing that there was a problem on the network providers side. Do we need to change anything in Asterisk?
By: Richard Mudgett (rmudgett) 2011-09-13 11:56:50.711-0500

The patch was intended to identify the problem since that was the only likely change that could have caused the symptoms.  I have reviewed the Q.931 and equivalent ETSI specifications.  Both documents say the PROGRESS message can be used when no call state change is appropriate.  The ETSI document is a little more explicit.  The PROGRESS message is only indicating that the network needs to attach to the B channel, if it has not done so already, for inband messages/tones to be passed to the caller.  The network is not handling the PROGRESS message correctly since it appears to be treating it like an ALERTING message.

I made Asterisk send the PROGRESS message ironically to make overlap dialing work so callers could hear the initial dialtone.  I had to use a separate PROGRESS message for libpri API backward compatibility reasons instead of putting the progress indicator ie in the SETUP ACKNOWLEDGE message.
By: Richard Mudgett (rmudgett) 2011-09-13 16:00:46.402-0500

I don't consider this issue a bug in Asterisk since it is plain that the network is not handling the PROGRESS message correctly.  However, if there are more people encountering this issue with their networks then this issue would need to be revisited.

By: Leif Madsen (lmadsen) 2011-09-13 16:03:01.813-0500

Closing this issue per Richard for now.