Summary: | ASTERISK-03398: SIP calls hangup with CVS from at least 21/01/05 onwards | ||
Reporter: | ennuyeux72 (ennuyeux72) | Labels: | |
Date Opened: | 2005-01-31 13:31:28.000-0600 | Date Closed: | 2005-02-09 17:53:09.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) astdeb2.txt ( 1) astdeb3.txt ( 2) astdeb4.rtf ( 3) ethereal.out.txt | |
Description: | Last known good CVS on 25/11/04 i.e problem did not occur. First known bad CVS on 21/01/05 i.e problems experienced. In the scenario where outgoing calls are made using a friend entity from an asterisk box via SIP to a provider, calls are being cut off after a fixed amount of seconds (19s). This problem does not appear with calls going out over IAX or calls going out over an E1. Nothing at all has changed on the provider side. The latest CVS HEAD also has the same problem. ****** ADDITIONAL INFORMATION ****** On various server makes Redhat 9 sip.conf [blablalba] type=friend username=blabla secret=blablb host=blalba disallow=ulaw disallow=ilbc disallow=gsm disallow=g729 | ||
Comments: | By: Brian West (bkw918) 2005-01-31 15:25:29.000-0600 WRONG.. attach a sip debug. bkw By: Brian West (bkw918) 2005-01-31 15:26:13.000-0600 Not major since i'm running 1/27 with my sipura and 7960's without any hangups. bkw By: Mark Spencer (markster) 2005-01-31 21:20:24.000-0600 Can you please attach a debug of this hangup situation and can you please try to establish precisely which days CVS of asterisk introduced the problem? By: Mark Spencer (markster) 2005-01-31 21:50:54.000-0600 Please continue in bug ASTERISK-3395 which appears to be a dupe of this one. By: ennuyeux72 (ennuyeux72) 2005-02-07 07:39:29.000-0600 The dupe bug has been closed. Have my own sip trace to post. Am not using a nated phone. By: Mark Spencer (markster) 2005-02-07 09:00:07.000-0600 You also appear to have nat=yes in your setup. Next time, also, please provide the output of Asterisk's sip debug which provides better detail about Asterisk's frame of reference than does ethereals. By: ennuyeux72 (ennuyeux72) 2005-02-07 09:32:36.000-0600 Have posted posted asterisk debug. nat=yes has been removed. UA is a on a public ip address By: Mark Spencer (markster) 2005-02-07 09:48:59.000-0600 This debug has all the returns stripped out of it! Can you please provide one that does not have the returns stripped out? By: ennuyeux72 (ennuyeux72) 2005-02-07 10:20:32.000-0600 didn't consciously strip out anything only did search and replace on company name here it is again: astdeb3 By: Mark Spencer (markster) 2005-02-08 01:34:51.000-0600 Carriage returns are still missing. By: ennuyeux72 (ennuyeux72) 2005-02-08 01:47:20.000-0600 sorry it seems i am being dense. the latest file was prepared with wordpad. To get the asterisk debug I just do a script -a /tmp/blabla, go to the cli enable the debug and then post the resultant file. What am I doing wrong? By: ennuyeux72 (ennuyeux72) 2005-02-08 08:17:03.000-0600 So was astdeb4.rtf ok? By: ennuyeux72 (ennuyeux72) 2005-02-08 08:17:57.000-0600 because it looks ok when i download and open it. By: linuss (linuss) 2005-02-08 12:02:06.000-0600 We have also found this problem. I've looked at the problem trace that the other user has posted, and have the following comments: (It's a cut and paste from an email sent to a user, with the Frame X references changed to match the debug trace supplied here) Look at Frame 28. This is the very first INVITE. The key thing to look at is the 'From: sip:' address. At this point, the call isnt authenticated, so in Frame 29 you get the 407 Authentication Required response. Now look at Frame 31, this is the 'real' authenticated INVITE, look again at the 'From:' address - this is different from Frame 28, but most importantly, this (in conjunction with the To: and Call-ID:) form the unique key that references this transaction. Anyway, the call progresses OK, until you get to Frame 51 where we send the 200 OK to tell you that the call answered. At this point, we need you to acknowledge this state, which you do, in Frame 52. *BUT* at this point, look at the 'From' address - this has now changed from the one in Frame 31, and so according to the specs would actually refer to a different transaction. Thus we refuse to accept it, so we timeout and send you another 200 OK, which again you don't acknowledge correctly, so ultimately we timeout, and kill the call. The bug is clearly that Asterisk incorrectly sets the 'From:' address in the second INVITE of a SIP authenticated outgoing call. Linus By: Mark Spencer (markster) 2005-02-08 13:31:27.000-0600 That particular bug should have already been fixed in CVS head. Linus: can you confirm you're still having such a problem with CVS Head? By: linuss (linuss) 2005-02-08 17:10:47.000-0600 I'm not directly myself - this is with client installs. If you can confirm when the fix entered CVS I can verify with the users concerned. Thanks! By: Mark Spencer (markster) 2005-02-08 17:48:29.000-0600 The fix for what you describe should already have been committed as of a few days ago. By: buzzydex (buzzydex) 2005-02-09 02:05:53.000-0600 The only mention of this bug seems to be in relation to the CVS build but I am having this problem with version 1.0.5. Also the CLID field seems to be getting confused with the number being called and it always shows the number being dialled instead of the correct CLID. By: ennuyeux72 (ennuyeux72) 2005-02-09 05:15:44.000-0600 ok using cvs head from about 8.00 am 8/2/5, the problem is fixed. Will conduct more tests and let you know. By: linuss (linuss) 2005-02-09 05:41:58.000-0600 Our feedback so far is also good, so I think this one was cleared. Thanks all. For the record though, can it be confirmed when this fault was actually introduced? By: Mark Spencer (markster) 2005-02-09 09:06:12.000-0600 Already fixed in CVS head. This bug was introduced when callerid stuff was changed recently (i.e. outbound gets the callerid of the extension by default). By: Russell Bryant (russell) 2005-02-09 17:53:09.000-0600 the callerid stuff has been reverted in stable, so it shouldn't be an issue there |