[Home]

Summary:ASTERISK-10900: While you are dialing from ATA/listening to the ring , if you press touchtone, then hangup, the other line rings forever.
Reporter:Andrew Gray (andrewgray)Labels:
Date Opened:2007-11-27 12:47:33.000-0600Date Closed:2011-06-07 14:03:06
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) putty2.log
( 1) putty3.log
Description:Verified on Asterisk 1.2.24, 1.2.14, 1.2.13, 1.2.9.

Using an ATA, if you dial another extension, and while you are listening to it ring, if you press a touchtone key sending out a DTMF tone, then hang up your phone, the other phone rings forever.

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

This bug was found on CentOS 4.5 running asterisk 1.2.24  and
on
FreeBSD 6.2 running asterisk 1.2.14, 1.2.13, and 1.2.9.  


This bug occurs every time it is done.  

Andrew Gray.

PS.

You say you want the SVN numbers.  How in the heck do you get them?
You say you want me to search the bug tracker.  How do you do that?

PUT LINKS!!!!
Comments:By: Joshua C. Colp (jcolp) 2007-11-27 12:52:51.000-0600

1. The SVN version number is only applicable if you are using an SVN checkout, and is available via svn info.

2. You put in what you want to search for in the field marked search and click apply filter.

3. We are no longer accepting bugs reported against 1.2, but I am leaving this open to give you a chance to confirm this issue against 1.4.
By: Joshua C. Colp (jcolp) 2007-11-27 12:53:49.000-0600

Oh and if it is still an issue we need the complete console output with sip debug.
By: Andrew Gray (andrewgray) 2007-11-27 14:53:52.000-0600

OK, we will compile asterisk 1.4 on Linux and see what happens

Andrew Gray
By: Andrew Gray (andrewgray) 2007-11-27 16:02:51.000-0600

OK, we loaded 1.4.14 and the same thing happened. We dialed an extension using an ATA, and while it was ringing, we pressed a DTMF key, and then hung our phone up.  The other phone kept right on ringing.  Except on the sip debug screen, it said that there was going to be timeout in 60 seconds, and sure enough, it quit  ringing after a minute or so.  So we went back to 1.2.24 and it also times out and stops ringing after a minute.  

With sip debug ON, there is so much activity on the terminal that it is impossible to cut and paste the sip debug output.  It scrolls by too fast.  So we are not able to get a sip debug output.  But it does it every time.  So it is not hard to reproduce.


Andrew Gray
By: Joshua C. Colp (jcolp) 2007-11-27 16:05:40.000-0600

sip debug peer <peer name> will only enable sip debug for that specific peer, I will try to reproduce it myself but I can't send DTMF before the remote side has answered... and console output would be useful too.
By: Andrew Gray (andrewgray) 2007-11-28 12:18:09.000-0600

OK, "sip debug peer <peer name>" worked fine.  So I used Putty to log the output while I used my ATA phone to press a '5' key DTMF tone while ringing, and hung up.  The other line kept ringing.  The log file is putty2.log, and I it can be found at

http://avtec.austin.com/putty2.log

and I will also upload it using your "Upload File" section.
Here is one thing interesting that I found in the log:

<------------->
--- (8 headers 0 lines) ---
 [Kasterisk2*CLI> * DTMF-relay event received: 5
 [Kasterisk2*CLI> Reliably Transmitting (no NAT) to 24.155.147.205:5060:
OPTIONS sip:andrew_ata2@24.155.147.205:5060 SIP/2.0
. . .

What is a DTMF relay event?  Notice that the event received is a '5', just like the DTMF '5' key that I pressed.

Andrew Gray


By: Joshua C. Colp (jcolp) 2007-11-28 12:26:19.000-0600

It's a DTMF digit received over the SIP signalling. In the log I see Asterisk calling a device, the device sending back a ringing indication, DTMF being received from somewhere, and finally the device sending back busy. Did you activate sip debug on the correct peer?
By: Andrew Gray (andrewgray) 2007-11-28 12:41:20.000-0600

I activated sip debug on the ATA that was ringing. (And not on the ATA that was the caller).  Is this what you wanted?


Andrew Gray
By: Joshua C. Colp (jcolp) 2007-11-28 12:43:39.000-0600

Nah, need one of the device placing the call into Asterisk. It is the one that signals hangup and the DTMF.
By: Andrew Gray (andrewgray) 2007-11-28 13:08:50.000-0600

OK.  So I did the same thing again, but this time I set the debug ON for the calling ATA peer.  The file name is putty3.log and can be found:

http://avtec.austin.com/putty3.log

And it is also uploaded using "Upload File" section.

Andrew Gray
By: Joshua C. Colp (jcolp) 2007-11-28 13:18:48.000-0600

This seems to be issue 5215 and a patch seems to be over there. Give it a try and report back for oej.
By: Andrew Gray (andrewgray) 2007-11-29 10:27:58.000-0600

OK.  Here is what issue 5215 said was the patch:

Asterisk also shouldn't ignore ACKs for the initial INVITE in a dialog that it has received requests for in the early dialog. The following patch works for me, but might let some requests through that should be ignored.


@@ -10329,7 +10330,8 @@
       if (option_debug > 2)
               ast_log(LOG_DEBUG, "**** Received %s (%d) - Command in SIP %s\n", sip_methods[p->method].text, sip_methods[p->method].id, cmd);

- if (p->icseq && (p->icseq > seqno)) {
+ if ((p->icseq && (p->icseq > seqno))
+ && !(!ast_test_flag(p, SIP_OUTGOING) && (req->method == SIP_ACK) &&
p->pendinginvite && (p->pendinginvite == seqno))) {
               ast_log(LOG_DEBUG, "Ignoring too old SIP packet packet %d (expecting >= %d)\n", seqno, p->icseq);
               return -1;
       } else if (p->icseq && (p->icseq == seqno) && req->method != SIP_ACK &&(p->method != SIP_CANCEL|| ast_test_flag(p, SIP_ALREADYGONE))) {
By: Andrew Gray (andrewgray) 2007-11-29 10:35:07.000-0600

This patch is for asterisk version 1.4.5.  But for version 1.4.14, I put this patch on line 15050 in chan_sip.c:

  if ((p->icseq && (p->icseq > seqno)) && !(!ast_test_flag(&p->flags[0], SIP_OUTGOING) && (req->method == SIP_ACK) && p->pendinginvite && (p->pendinginvite == seqno))) {
if (option_debug)
   ast_log(LOG_DEBUG, "Ignoring too old SIP packet packet %d (expecting >= %d)\n", seqno, p->icseq);
if (req->method != SIP_ACK)
transmit_response(p, "503 Server error", req); /* We must respond according to RFC 3261 sec 12.2 */
return -1;
} else if (p->icseq &&
  p->icseq == seqno &&
  req->method != SIP_ACK &&
  (p->method != SIP_CANCEL || ast_test_flag(&p->flags[0], SIP_ALREADYGONE))) {
By: Andrew Gray (andrewgray) 2007-11-29 10:39:42.000-0600

Notice that in chan_sip.c in version 1.4.5

  ast_test_flag(p, SIP_OUTGOING)

must be changed to in version 1.4.14

  ast_test_flag(&p->flags[0], SIP_OUTGOING)

Correct?

So I deleted ../asterisk-1.4.14/main/asterisk and remade.

It did not seem to stop the ringing problem.

Issue 5215 guy says:

"The following patch works for me, but might let some requests through that should be ignored."

Maybe this is the case?


Andrew Gray
By: Andrew Gray (andrewgray) 2007-11-29 10:41:42.000-0600

So, are we on the right track here, or should I just go and remove all DTMF relay stuff so asterisk will work for us?


Andrew Gray


By: Andrew Gray (andrewgray) 2007-12-04 10:36:59.000-0600

So Will removing all instances of DTMF Relay fix our problem (just for us)?

Andrew Gray
By: Olle Johansson (oej) 2008-02-03 04:43:50.000-0600

Can you please check with latest 1.4 from svn? I fixed a similar issue today. Thanks.
By: Andrew Gray (andrewgray) 2008-02-09 23:31:02.000-0600

I would be glad to check this, but again please forgive my ignorance.  I did find

http://svn.digium.com/view/asterisk/branches/1.4/

but these are all individual files.  

1) Am I supposed to download all the individual files one by one, or is there somewhere I can get a snapshot of the whole "SVN" thing?

2)  Are there particular files that you fixed that can be applied to version 1.4.18 in a piecemeal fashion?  I can get 1.4.18.  

3) Or, does 1.4.18 contain your "latest SVN" fixes?

Andrew Gray
By: jmls (jmls) 2008-02-17 14:33:38.000-0600

Andrew ... go to http://www.asterisk.org/developers/get-source and have a look there.
By: Joshua C. Colp (jcolp) 2008-03-04 13:52:26.000-0600

I have created a scenario and confirmed this is fixed in the latest 1.4.