[Home]

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-0600Date Closed:2005-02-09 17:53:09.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:
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