[Home]

Summary:ASTERISK-09216: [patch] Asterisk sends wrong CSEQ in CANCEL if using INFO dtmf
Reporter:Vadim Berezniker (kryptolus)Labels:
Date Opened:2007-04-06 09:40:08Date Closed:2008-02-03 10:43:42.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug9492.txt
( 1) ignore_info.patch
Description:SIP RFC states that a CANCEL to an INVITE must have the same CSEQ as the INVITE. When asterisk sends INFO packets, it increments the ocseq counter. When it sends the CANCEL, the cseq is not that of the INVITE but of the last INFO.

(Please don't ask me for logs... they're not going to say anything more than what I just said above. )

This is a big problem as the other party thinks the call is still going (it rejects the improper CANCEL).
Comments:By: Serge Vecher (serge-v) 2007-04-06 12:09:22

s per bug guidelines, you need to attach a SIP debug trace illustrating the problem. Please do the following:
1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterisk with the following command:
  'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt'
4) Enable SIP transaction logging with the following CLI commands (1.4/trunk commands in parenthesis):
set debug 4 (core set debug 4)
set verbose 4 (core set verbose 4)
sip debug (sip set debug)
5) Reproduce the problem
6) Trim startup information and attach verbosedebug.txt to the issue.
By: Vadim Berezniker (kryptolus) 2007-04-06 12:24:57

You got to be joking me. This is a real problem and all the necessary information needed is above. The logs will not add anything and are a waste of time for me. This is not an intermittent issue and is easily seen in the code. I'm tired of this attitude. Not all issues require logs, and as a software developer I know when they do. Feel free to close this bug, I will not open any new ones.
By: Serge Vecher (serge-v) 2007-04-06 12:45:27

kryptolus, I've asked for the logs not to annoy you, but to help along with the resolution of the problem. Your analysis maybe valid (I'm not a sip code expert), but without the logs it may take a lot of time for a developer to set up a test environment to confirm this.

since this can be easily seen in the code, can you please propose a patch fixing it?
By: Vadim Berezniker (kryptolus) 2007-04-09 07:16:26

I looked over the code this weekend, and there are multiple places that would need to be fixed. Since this issue, I presume, is probably gone in 1.4, it's not worth spending a lot of time to fix. I'll try using the attached band-aid.

It basically drops any INFO messages until the channel is up. While it's not the ideal solution, it works. Sending INFO before the channel is up screws up asterisk anyway, so I don't really see a downside to it.
By: Vadim Berezniker (kryptolus) 2007-04-09 07:20:03

This patch also works for the bug I filed before, bug 9408.
By: Serge Vecher (serge-v) 2007-04-09 11:51:19

thanks, kryptolus. I'll close the other bug then.
By: Olle Johansson (oej) 2007-04-10 02:13:36

THis is a duplicate bug report. I will look into the patch. The reason why it wasn't fixed even though it's a very old bug report (the other one) is that it is hard to fix properly without a major rewrite to include decent transaction support - something that is the foundation for Codename Pineapple (chan_sip3)
By: Olle Johansson (oej) 2007-05-09 08:58:11

This patch is really a work-around... Maybe there's a better, but still ugly way to solve it and keep the DTMF. Sometimes DTMF is needed for IVRs in early media. Ugly, but still needed.
By: Olle Johansson (oej) 2007-05-16 05:14:30

Please try the patch in ASTERISK-5077 and tell us if it helps. Thank you!
By: Andrew Gray (andrewgray) 2007-11-28 15:29:22.000-0600

OK.  Here is what issue 5215 says a patch should be:

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-28 15:36:47.000-0600

This is for version 1.4.5, but for 1.4.14 I put in the follow patch on line 15505 of chan_sip.c, then remade asterisk:

  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-28 15:41:50.000-0600

Notice that

ast_test_flag(p, SIP_OUTGOING)

must be changed to:

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

Correct?

I deleted the old asterisk in  asterisk-1.4.14/main.  Remade asterisk,
then copied the new asterisk into /usr/sbin/asterisk.  Reran.

But this did not fix the ringing bug.  He says:

"... but might let some requests through that should be ignored."

I wonder if that is the case.

Andrew Gray


By: Olle Johansson (oej) 2008-01-30 10:53:18.000-0600

Here's a patch that will use the invite's CSEQ for the CANCEL. Applies to 1.4.

Please test!

/O
By: Andrew Gray (andrewgray) 2008-01-31 11:46:30.000-0600

oej,

This is Andrew Gray.  Forgive me, but you say "here is a patch" to try, but I do not see how to get it.  Below, I see that you added the file

bug9492.txt

Is this the patch?  If so, how do I get it?
If not, where is the patch?


Andrew Gray
By: Olle Johansson (oej) 2008-01-31 12:21:23.000-0600

Yes, it's the patch. Click on it to download.
By: Digium Subversion (svnbot) 2008-02-03 10:35:14.000-0600

Repository: asterisk
Revision: 102142

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r102142 | oej | 2008-02-03 10:35:13 -0600 (Sun, 03 Feb 2008) | 8 lines

Use the same CSEQ on CANCEL as on INVITE (according to RFC 3261)

(closes issue ASTERISK-9216)
Reported by: kryptolus
Patches:
     bug9492.txt uploaded by oej (license 306)
Tested by: oej

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

http://svn.digium.com/view/asterisk?view=rev&revision=102142
By: Digium Subversion (svnbot) 2008-02-03 10:43:42.000-0600

Repository: asterisk
Revision: 102143

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r102143 | oej | 2008-02-03 10:43:41 -0600 (Sun, 03 Feb 2008) | 16 lines

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

........
r102142 | oej | 2008-02-03 17:38:12 +0100 (S?�95?Y?�94?�82n, 03 Feb 2008) | 8 lines

Use the same CSEQ on CANCEL as on INVITE (according to RFC 3261)

(closes issue ASTERISK-9216)
Reported by: kryptolus
Patches:
     bug9492.txt uploaded by oej (license 306)
Tested by: oej

........

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

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