[Home]

Summary:ASTERISK-03578: [patch] Fix improper ignoring of second SIP INVITE messages on slow links
Reporter:twisted (twisted)Labels:
Date Opened:2005-02-24 16:39:21.000-0600Date Closed:2008-01-15 15:49:14.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asgi-sip-patch.2.txt
( 1) asgi-sip-patch.txt
( 2) asgi-sip-patch-stable.txt
( 3) 3658patch
( 4) Sipdebug3658
Description:This patch was created by Martin Pycko on contract by us to solve an issue with Sipura 2k's and Linksys PAP's where on a slow link (>500ms latency) the duplicate INVITE would cause the incoming call to fail with "Unable to create/find channel" messages.  This patch has no adverse effect on normal sip communications, and has solved the issue completely.

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

This patch, as created under contract, is the property of Asteria Solutions Group, thus our disclaimer fully applies, and is on file.
Comments:By: twisted (twisted) 2005-02-24 17:43:04.000-0600

For clarification, this bug exists on both stable and head, thus the supplied patches for both. ;)
By: () 2005-02-25 21:18:58.000-0600

I had been seeing those too, began to just ignore them :) Thanks for the quick fix.
By: Mark Spencer (markster) 2005-02-25 22:17:02.000-0600

This is actually still incorrect.  If we receive another "INVITE" we still should generate the proper response for it immediately, not just wait for retransmission.  That's why we mess with it in the first place.  I'll try to simulate and fix it
By: damin (damin) 2005-03-11 01:24:56.000-0600

As of Asterisk CVS-v1-0-03/11/05-02:02:16, the stable patch does not apply cleanly. It is most likely a trivial fix:

[root@asterisk channels]# more chan_sip.c.rej
***************
*** 7279,7286 ****      
                       /* Queue NULL frame to prod ast_rtp_bridge if appropriate */
                       if (p->owner)
                               ast_queue_frame(p->owner, &af);
-               } else if (debug)
                       ast_verbose("Ignoring this request\n");
               if (!p->lastinvite && !ignore && !p->owner) {
                       /* Handle authentication if this is our first invite */
                       res = check_user(p, req, cmd, e, 1, sin, ignore);
--- 7280,7290 ----      
                       /* Queue NULL frame to prod ast_rtp_bridge if appropriate */
                       if (p->owner)
                               ast_queue_frame(p->owner, &af);
+               } else {
+                       if (debug)
                       ast_verbose("Ignoring this request\n");
+                       really_ignore = 1;
+               }
               if (!p->lastinvite && !ignore && !p->owner) {
                       /* Handle authentication if this is our first invite */
                       res = check_user(p, req, cmd, e, 1, sin, ignore);
By: brc007 (brc007) 2005-03-11 01:45:50.000-0600

Uploaded asgi-sip-patch.2.txt. Should apply cleanly now
By: Olle Johansson (oej) 2005-03-19 15:55:03.000-0600

I would like to see a SIP debug of when this happens, to understand this patch. Is the situation that we have answered the first INVITE and then get a copy of it, or is it something else? If we get a copy of an INVITE that we already sent 200 OK to, we should handle that - as Markster said.
By: Olle Johansson (oej) 2005-03-23 02:30:40.000-0600

Look at ASTERISK-3730 and ASTERISK-3727 - related problems.
By: Kevin P. Fleming (kpfleming) 2005-03-23 09:06:13.000-0600

Yes, I think this patch is just a bit too aggressive, because if the second INVITE is for one we have already started handling (we are ing "Proceeding" state) we are supposed to retransmit the previous response.

The existing code will do that, by virtue of the fact that the pvt structure will have a channel (->owner) when the second INVITE arrives, and block of code starting with 'if (c) {...' will get executed.

twisted, please try the less aggressive patch(es) that are in bug ASTERISK-3793820 to see if they also solve the problem for you.
By: Michael Jerris (mikej) 2005-05-15 12:16:47

Do the patches from 3820 resolve this issue as well?
By: Michael Jerris (mikej) 2005-05-15 12:18:16

oej, 3820 was closed as merged with another bug.  What bug was it merged too?  Also, 3817 seems to be a duplicate, can we consolodate 3817 and this bug as well?
By: twisted (twisted) 2005-05-15 18:42:50

Unfortunately, I no longer have access to the systems I could produce this problem on, so I will be unable to test.
By: Daniel Hope (daniel) 2005-05-18 15:04:13

I've been having problems with this also, I applied the patch from 3820 which seems to fix the problem - that is - putting the check for (!ignore) around the block that schedules the channel to be cancelled. I'm running CVS code from Feb 22 2005.

I tested with several UA's - a Cisco ATA186, an Epygi2x, and a Zoom5 - I connected them to Asterisk through a FreeBSD network bridge running dummynet to simulate packet delay (http://info.iet.unipi.it/~luigi/ip_dummynet/ has a good explanation how it works - I can send my configs if people are interested).

As a work-around, you can also disable authentication by password for the given user in sip.conf and authenticate via IP address instead. We did this for many of our customers on Satellite links.
By: Michael Jerris (mikej) 2005-06-27 23:21:50

oej-  What is the deal with this one.  It seems we have a tested fix on a closed bug??
By: Olle Johansson (oej) 2005-07-31 15:28:06

Please check if ASTERISK-4257 helps.
By: Michael Jerris (mikej) 2005-08-24 00:42:42

daniel-  Can you please retest in your test environment with current cvs head.  A potential fix has been commited.
By: Olle Johansson (oej) 2005-08-24 01:57:39

Make sure you have qualify=on on the peer you test.
By: Olle Johansson (oej) 2005-08-24 01:58:06

BTW; the other patch is included in CVS head, so test with updated CVS head.
By: Michael Jerris (mikej) 2005-08-30 23:37:53

ok, seeing as we have no response on this, I am going to assume this is fixed.  If it is not, please re-open this bug.
By: Russell Bryant (russell) 2005-09-08 20:49:09

Reopened at the request of jskcr on IRC
By: Jay K (jskcr) 2005-09-08 20:57:18

I going to work on a fix for this one during the weekend.
For now if you would like to duplicate the problem on your linux box.
Download http://snad.ncsl.nist.gov/itg/nistnet/ .
This will allow you to simulate the problem. Just set the latency to 1000ms
By: Olle Johansson (oej) 2005-09-09 04:18:19

Can we get a SIP debug that shows the problem from someone, please?
By: Jay K (jskcr) 2005-09-09 07:42:00

Oej, I attached a sip debug that shows the problem in action :)

Also http://bugs.digium.com/view.php?id=3820 was merged with this one.
3820 is/was considered a major bug. Can we have this one changed from minor to major since it effects anyone who uses asterisk over a high latency connection IE:satellite users


By: Olle Johansson (oej) 2005-09-09 07:51:05

Sorry, as always we need a SIP debug with debug set to 4, verbose set to 4 and make sure that debug hits the console. Thank you.
By: Olle Johansson (oej) 2005-09-09 07:54:59

Reading this SIP debug, everything is fine. We are ignoring the re-transmit of the INVITE while waiting for an ACK on the auth request. We should *not* send 488 on that, that's a bug, we should retransmit the auth request.

Anyway, when we finally get a new INVITE with a new cseq and auth, that one is accepted. Maybe the phone then reacted to the confusing 488 and gave up. Tell me what happened with this call?
By: Jay K (jskcr) 2005-09-09 08:16:21

Oej, Yup your right,
I changed this is chan_sip.c and it fixed the problem


if (p && !ast_test_flag(p, SIP_NEEDDESTROY)) {
                       if (!p->jointcapability) {

if (p && !ast_test_flag(p, SIP_NEEDDESTROY) && !ignore) {
                       if (!p->jointcapability) {
The 488 is the problem,


By: Olle Johansson (oej) 2005-09-09 08:19:17

So what kind of reply do you get now?

Can you provide a patch?
By: Jay K (jskcr) 2005-09-09 08:44:21

It properly handles the 488, acording to rfc3261 13.2.2
By: Olle Johansson (oej) 2005-09-09 10:38:23

We need to know if you have a disclaimer on file for this patch before we process it or even look at it.
By: Jay K (jskcr) 2005-09-09 10:56:47

Noper whats the link for the disclaimer, ill put one on file
By: Olle Johansson (oej) 2005-09-09 11:28:18

Go to the bug tracker home page and read the instructions!
By: Jay K (jskcr) 2005-09-09 12:08:45

The disclaimer has been faxed
By: Olle Johansson (oej) 2005-09-15 04:50:23

Ready for cvs.
By: Kevin P. Fleming (kpfleming) 2005-09-25 23:08:51

Committed to CVS HEAD, thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:49:14.000-0600

Repository: asterisk
Revision: 6660

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6660 | kpfleming | 2008-01-15 15:49:13 -0600 (Tue, 15 Jan 2008) | 2 lines

properly ignore retransmitted INVITEs on long latency links (issue ASTERISK-3578)

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

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