ASTERISK-15594: [patch] Overlap receiving timeout, plus dialplan latency, causes network to retry SETUP

[Home]

Summary: ASTERISK-15594: [patch] Overlap receiving timeout, plus dialplan latency, causes network to retry SETUP

Reporter: Alec Davis (alecdavis) Labels:

Date Opened: 2010-02-08 19:57:08.000-0600 Date Closed: 2011-01-25 11:58:01.000-0600

Priority: Minor Regression? No

Status: Closed/Complete Components: Channels/chan_dahdi

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) overlap_receiving_trunk.diff.txt
( 1) overlap_receiving.diff.txt
( 2) overlap_receiving.diff2.txt
( 3) overlapdial-jtec-trace.txt
( 4) overlapdial-retry.txt

Description: An overlap received call, should have a PROCEEDING sent when asterisk has deemed that no further digits are coming, IE when asterisk starts executing the dialplan.

The issue is, ast_waitfordigit in ss_thread waits 'matchdigittimeout' which set 3 seconds, then there is dialplan delay, which may take a while to execute PROGRESS(), PROGRESS() or ANSWER(). In our case, database lookups.

When the network retries the SETUP, with the same channel and call reference, libpri deems this as a 'Not a new call' and promptly rejects the call. Now the call is lost!.

Previously it has required the PROCEEDING() to be the the first line of the dialplan context.

****** ADDITIONAL INFORMATION ******

Reference Q.931 5.2.4<pre>

Following the receipt of a sending complete indication which the user understands, or the determination that sufficient call information has been received, the user shall stop timer T302 (if implemented) and send a CALL PROCEEDING message to the network. Alternatively, depending
on internal events, the user may send an ALERTING or a CONNECT message to the network</pre>

Comments: By: Alec Davis (alecdavis) 2010-02-08 20:05:48.000-0600

Have a repeatable situation. See overlap-retry.txt

This is a capture before the applied patch. With 2 SETUP's with the same call reference and channel.

An overlap call comes in, 3 seconds later asterisk starts to make the call, but the switch hasn't seen anything back, other than the SETUP ACK.

As a workaround adding a PROCEEDING to the first line of the macro that gets executed, I couldn't get it to fail, like below.

[macro-callmobile]
exten => s,1,Proceeding()
exten => s,n,NoOp(****** Call Mobile called=${ARG1} context=${MACRO_CONTEXT} ******)

Q.931 spec 5.2.4, 'overlap receiving' section mentions that Proceeding, or Alerting etc should be sent after T302 times out, if asterisk deems that it's received enough information to make the call.

By: Alec Davis (alecdavis) 2010-02-09 17:46:27.000-0600

Below is a capture to our Telco from our Jtec Switch, using overlap dialling, asterisk isn't involved with this call.

This shows that the TELCO send back a PROCEEDING before the ALERTING, as I am proposing.<pre>
0395 USER 100210 12:31:43.99 Q.931 SETUP C/Ref 0C01 Org
0397 NETWORK 100210 12:31:44.15 Q.931 SETUP ACKnowledge C/Ref 0C01 Dest
0399 USER 100210 12:31:45.41 Q.931 INFOrmation C/Ref 0C01 Org
0401 USER 100210 12:31:45.91 Q.931 INFOrmation C/Ref 0C01 Org
0403 USER 100210 12:31:46.29 Q.931 INFOrmation C/Ref 0C01 Org
0405 USER 100210 12:31:46.57 Q.931 INFOrmation C/Ref 0C01 Org
0407 USER 100210 12:31:47.06 Q.931 INFOrmation C/Ref 0C01 Org
0413 USER 100210 12:31:47.39 Q.931 INFOrmation C/Ref 0C01 Org
0418 USER 100210 12:31:47.72 Q.931 INFOrmation C/Ref 0C01 Org
0423 USER 100210 12:31:50.96 Q.931 INFOrmation C/Ref 0C01 Org
0425 USER 100210 12:31:51.62 Q.931 INFOrmation C/Ref 0C01 Org
0429 NETWORK 100210 12:31:52.44 Q.931 CALL PROCeeding C/Ref 0C01 Dest
0431 NETWORK 100210 12:31:53.38 Q.931 ALERTing C/Ref 0C01 Dest
0433 USER 100210 12:31:54.86 Q.931 DISConnect C/Ref 0C01 Org
0435 NETWORK 100210 12:31:55.03 Q.931 RELease C/Ref 0C01 Dest
0437 USER 100210 12:31:55.08 Q.931 RELease COMplete C/Ref 0C01 Org</pre>

edit: Same setup as this example, just a different day.
added full trace from Jtec to Telco. See attached file overlapdial-jtec-trace.txt

By: klaus3000 (klaus3000) 2010-02-10 02:20:43.000-0600

I'm not familiar with the actual problem, but if CALL PROCEEDING is sent automatically I think you should check that the CALL PROCEEDING message does not indicate that inband-information is available (as there is none).
By: Birger "WIMPy" Harzenetter (wimpy) 2010-02-10 04:55:30.000-0600

I wonder why you run into a timeout in the first place.

I think you should check your config, incl. dialplan.
By: Alec Davis (alecdavis) 2010-02-10 05:27:57.000-0600

I've misreported this in the description, the call doesn't get lost.

With a test dialplan like below it can be seen.
The first setup has been seen and is executing
A second setup comes in during the Wait(1), and is ignored (call isn't lost)
The call then completes.

[incoming]
exten => _0274000X.,1,Wait(1)
exten => _0274000X.,2,Answer()
exten => _0274000X.,3,Playback(goodbye)
By: Alec Davis (alecdavis) 2010-02-10 05:35:03.000-0600

Taking klaus3000's suggestion

overlap_receiving.diff2.txt

With inbound overlap receiving when asterisk deems no further digits are coming, indicate Call Proceeding just before dialplan starts executing.
But don't indicate inband-information as available yet.
By: Alec Davis (alecdavis) 2010-02-10 05:41:41.000-0600

Wimpy:
We see a timeout, which doesn't seem to be configurable on our switch.
The Q.931 standard implies a Proceeding should be sent.
Our Telco send a Proceeding when it's deemed enough digits have been dialled.

thus: it seems like the right thing to do.
By: Alec Davis (alecdavis) 2010-02-16 17:16:34.000-0600

There is a difference in the SETUP ACKNOWLEDGE between Asterisk overlap receive dialling and our Telco.

The Setup Acknowledge from TELCO with an overlap call has progress indicator, 'In-band info/approp patt now avail', as seen in overlapdial-jtec-trace.txt

The Setup Ack from asterisk with overlap receiving doesn't?? This can be seen in overlap-retry.txt

We may need to receive more INFO's.

edit:
With no digits in callednumber in SETUP message the SETUP ACK should be 'In-band info/approp patt now avail', with dialtone also provided.

By: Alec Davis (alecdavis) 2010-02-23 03:52:51.000-0600

overlap_receiving.diff2.txt for 1.6.1 svn branch.
overlap_receiving_trunk.diff.txt for trunk.
By: Digium Subversion (svnbot) 2010-02-27 16:49:53.000-0600

Repository: asterisk
Revision: 249320

U trunk/channels/sig_pri.c

------------------------------------------------------------------------
r249320 | alecdavis | 2010-02-27 16:49:52 -0600 (Sat, 27 Feb 2010) | 18 lines

overlap receiving: automatically send CALL PROCEEDING when dialplan starts

Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.

Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.

Verified that our local TELCO also does the same.

(issue ASTERISK-15594)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=249320
By: Digium Subversion (svnbot) 2010-02-27 17:04:03.000-0600

Repository: asterisk
Revision: 249321

U branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r249321 | alecdavis | 2010-02-27 17:04:03 -0600 (Sat, 27 Feb 2010) | 18 lines

overlap receiving: automatically send CALL PROCEEDING when dialplan starts

Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.

Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.

Verified that our local TELCO also does the same.

(issue ASTERISK-15594)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=249321
By: Digium Subversion (svnbot) 2010-02-27 17:37:17.000-0600

Repository: asterisk
Revision: 249363

U branches/1.6.1/channels/chan_dahdi.c

------------------------------------------------------------------------
r249363 | alecdavis | 2010-02-27 17:37:17 -0600 (Sat, 27 Feb 2010) | 18 lines

overlap receiving: automatically send CALL PROCEEDING when dialplan starts

Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.

Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.

Verified that our local TELCO also does the same.

(issue ASTERISK-15594)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=249363
By: Digium Subversion (svnbot) 2010-02-27 17:38:43.000-0600

Repository: asterisk
Revision: 249364

U branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r249364 | alecdavis | 2010-02-27 17:38:43 -0600 (Sat, 27 Feb 2010) | 19 lines

overlap receiving: automatically send CALL PROCEEDING when dialplan starts

Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.

Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.

Verified that our local TELCO also does the same.

(issue ASTERISK-15594)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

(closes issue ASTERISK-15594)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=249364
By: Digium Subversion (svnbot) 2010-02-27 17:51:28.000-0600

Repository: asterisk
Revision: 249365

U branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r249365 | alecdavis | 2010-02-27 17:51:28 -0600 (Sat, 27 Feb 2010) | 19 lines

overlap receiving: automatically send CALL PROCEEDING when dialplan starts

Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.

Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.

Verified that our local TELCO also does the same.

(issue ASTERISK-15594)
Reported by: alecdavis
Patches:
based on overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

(closes issue ASTERISK-15594)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=249365
By: Digium Subversion (svnbot) 2011-01-25 11:36:51.000-0600

Repository: asterisk
Revision: 303765

U branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r303765 | rmudgett | 2011-01-25 11:36:51 -0600 (Tue, 25 Jan 2011) | 40 lines

Sending out unnecessary PROCEEDING messages breaks overlap dialing.

Issue ASTERISK-15594 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".

Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.

* Effectively revert issue ASTERISK-15594.

* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.

* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.

* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.

* Added diagnostic messages for deferred overlap digits handling corner
cases.

(closes issue ASTERISK-15865)
Reported by: shawkris

(closes issue ASTERISK-17141)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=303765
By: Digium Subversion (svnbot) 2011-01-25 11:42:43.000-0600

Repository: asterisk
Revision: 303769

_U branches/1.6.2/
U branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r303769 | rmudgett | 2011-01-25 11:42:43 -0600 (Tue, 25 Jan 2011) | 47 lines

Merged revisions 303765 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40 lines

Sending out unnecessary PROCEEDING messages breaks overlap dialing.

Issue ASTERISK-15594 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".

Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.

* Effectively revert issue ASTERISK-15594.

* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.

* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.

* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.

* Added diagnostic messages for deferred overlap digits handling corner
cases.

(closes issue ASTERISK-15865)
Reported by: shawkris

(closes issue ASTERISK-17141)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=303769
By: Digium Subversion (svnbot) 2011-01-25 11:49:22.000-0600

Repository: asterisk
Revision: 303771

_U branches/1.8/
U branches/1.8/channels/chan_dahdi.c
U branches/1.8/channels/sig_pri.c
U branches/1.8/channels/sig_pri.h
U branches/1.8/channels/sig_ss7.c
U branches/1.8/channels/sig_ss7.h

------------------------------------------------------------------------
r303771 | rmudgett | 2011-01-25 11:49:21 -0600 (Tue, 25 Jan 2011) | 54 lines

Merged revisions 303769 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
r303769 | rmudgett | 2011-01-25 11:42:42 -0600 (Tue, 25 Jan 2011) | 47 lines

Merged revisions 303765 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40 lines

Sending out unnecessary PROCEEDING messages breaks overlap dialing.

Issue ASTERISK-15594 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".

Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.

* Effectively revert issue ASTERISK-15594.

* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.

* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.

* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.

* Added diagnostic messages for deferred overlap digits handling corner
cases.

(closes issue ASTERISK-15865)
Reported by: shawkris

(closes issue ASTERISK-17141)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett
........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=303771
By: Digium Subversion (svnbot) 2011-01-25 11:58:01.000-0600

Repository: asterisk
Revision: 303772

_U trunk/
U trunk/channels/chan_dahdi.c
U trunk/channels/sig_pri.c
U trunk/channels/sig_pri.h
U trunk/channels/sig_ss7.c
U trunk/channels/sig_ss7.h

------------------------------------------------------------------------
r303772 | rmudgett | 2011-01-25 11:58:01 -0600 (Tue, 25 Jan 2011) | 61 lines

Merged revisions 303771 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
r303771 | rmudgett | 2011-01-25 11:49:20 -0600 (Tue, 25 Jan 2011) | 54 lines

Merged revisions 303769 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
r303769 | rmudgett | 2011-01-25 11:42:42 -0600 (Tue, 25 Jan 2011) | 47 lines

Merged revisions 303765 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40 lines

Sending out unnecessary PROCEEDING messages breaks overlap dialing.

Issue ASTERISK-15594 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".

Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.

* Effectively revert issue ASTERISK-15594.

* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.

* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.

* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.

* Added diagnostic messages for deferred overlap digits handling corner
cases.

(closes issue ASTERISK-15865)
Reported by: shawkris

(closes issue ASTERISK-17141)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett
........
................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=303772