Error in logs on call ringing

Hi all,

I have this Dual Dual Core Xeon 3.8 with about 50 Cisco SPA504G Phones.
Everything is in a dedicated VLAN or Network for VOIP.

We receive calls from a DAHDI T1 Card with Echo Cancel and that goes to the IVR
Asterisk Version is: Asterisk 1.8.4.1-1digium1~squeeze
This one is for Debian downloaded from the official asterisk repository.

When a you dial an extensions and the phone starts ringing, i get an error likes a 10000 per second until the phone stops ringing an someone takes the call

The problem is that the asterisk service is stops working like every 3 hours.
I’m trying to check what is happening and i think this may be flooding the server

[quote][Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame
[Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame
[Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame
[Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame
[Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame
[Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame
[Jun 8 19:56:08] DEBUG[5993]: res_rtp_asterisk.c:1204 ast_rtp_write: No remote address on RTP instance ‘0xb4502b80’ so dropping frame[/quote]

What is causing this? and how can i fix this?
Thanks for everything.

What’s causing this is that you have debugging enabled. It is expected that you will get flooded with messages if you do that.

You would need to look at the SDP exchanges to see why RTP setup was incomplete.

Yes, i have debug enabled.
I want to know why the service stop working like every 3 hours.
I’m discarding all the possibilities.

This is happening after i installed the 1.8.
How do i look at the SDP exchanges?

sip set debug on

or wireshark

Hey,

I dont see anything that could help
I got this.

[quote]SIP Debugging Enabled for IP: 10.0.0.152
prod-voip*CLI>
== CDR updated on DAHDI/1-1
== Using SIP RTP CoS mark 5
Audio is at 5060
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.0.0.152:5060:
INVITE sip:247@10.0.0.152:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Max-Forwards: 70
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
To: sip:247@10.0.0.152:5060
Contact: sip:asterisk@10.0.0.23:5060
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.4.1-1digium1~squeeze
Date: Fri, 10 Jun 2011 23:14:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 255

v=0
o=root 1712010044 1712010044 IN IP4 10.0.0.23
s=Asterisk PBX 1.8.4.1-1digium1~squeeze
c=IN IP4 10.0.0.23
t=0 0
m=audio 31312 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


<— SIP read from UDP:10.0.0.152:5060 —>
SIP/2.0 100 Trying
To: sip:247@10.0.0.152:5060
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Server: Cisco/SPA504G-7.4.3a
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:10.0.0.152:5060 —>
SIP/2.0 180 Ringing
To: sip:247@10.0.0.152:5060;tag=e8122d211e020b50i0
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Contact: “247” sip:247@10.0.0.152:5060
Server: Cisco/SPA504G-7.4.3a
Content-Length: 0

<------------->
— (9 headers 0 lines) —
Scheduling destruction of SIP dialog ‘4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060’ in 32000 ms (Method: INVITE)
Reliably Transmitting (no NAT) to 10.0.0.152:5060:
CANCEL sip:247@10.0.0.152:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Max-Forwards: 70
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
To: sip:247@10.0.0.152:5060
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.8.4.1-1digium1~squeeze
Content-Length: 0


Scheduling destruction of SIP dialog ‘4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060’ in 32000 ms (Method: INVITE)
== Spawn extension (llamar_dentro, sw_11_“interno”, 14) exited non-zero on ‘DAHDI/1-1’

<— SIP read from UDP:10.0.0.152:5060 —>
SIP/2.0 487 Request Terminated
To: sip:247@10.0.0.152:5060;tag=e8122d211e020b50i0
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Server: Cisco/SPA504G-7.4.3a
Content-Length: 0

<------------->
— (8 headers 0 lines) —
Transmitting (no NAT) to 10.0.0.152:5060:
ACK sip:247@10.0.0.152:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Max-Forwards: 70
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
To: sip:247@10.0.0.152:5060;tag=e8122d211e020b50i0
Contact: sip:asterisk@10.0.0.23:5060
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.4.1-1digium1~squeeze
Content-Length: 0


<— SIP read from UDP:10.0.0.152:5060 —>
SIP/2.0 200 OK
To: sip:247@10.0.0.152:5060;tag=e8122d211e020b50i0
From: “asterisk” sip:asterisk@10.0.0.23;tag=as69f44704
Call-ID: 4605e0fa438057d66e93f3b220f3459d@10.0.0.23:5060
CSeq: 102 CANCEL
Via: SIP/2.0/UDP 10.0.0.23:5060;branch=z9hG4bK61bdc072
Server: Cisco/SPA504G-7.4.3a
Content-Length: 0

<------------->
— (8 headers 0 lines) —[/quote]

Do you see something there?

thx

Outgoing call offered ulaw (mu-law, G.711) codec.

Never answered.

Call was dropped by the dahdi side before answer.

The failure to answer lies entirely with the downstream side. The reasons for clearing relate to the dahdi side, and presumably indicate that the caller hung up. You will need to turn on dahdi debugging to find out why Asterisk thinks the caller abandoned the call. I don’t have dahdi lines, so I don’t have direct experience of debugging dahdi connections.

The dahdi driver should be sourcing the ringback tone.

I am pretty certain that your debug message is simply the result of the call being unanswered, and therefore Asterisk never having received the destination address for the media on the VoIP side.

In the sequence you have captured here, Asterisk appears to be working all the time, and IP is flowing in both directions. If this was taken in a fault scenario, and the basic symptom is that calls stop being answered, the downstream system has the problem.

Hello again
Please, read this and check if you can give me some ideas.

This server has a particular problem, it goes down about 2 or 3 times at day.
But its not that the service crashes, its just that when i do asterisk -rvvv, then i do core show channels, it doesnt know anything.

The dahdi interface stop working and the sip doesnt work. It just show things like CoS 5, Cos 6 sometimes.
I tried to check with wireshark but the network is clean.

I put the debugging in 5 to see if there is something not normal but it shows everything it does all the time.
I had asterisk 1.6, and when the problem started happening i started getting this error in debug 5

[Jun 6 15:34:58] DEBUG[5391] channel.c: Avoiding deadlock for channel ‘0x7f4c380049d0’
[Jun 6 15:34:58] DEBUG[5391] channel.c: Avoiding deadlock for channel ‘0x7f4c380049d0’
[Jun 6 15:34:58] DEBUG[5391] channel.c: Avoiding deadlock for channel ‘0x7f4c380049d0’
[Jun 6 15:34:58] DEBUG[5391] channel.c: Avoiding deadlock for channel ‘0x7f4c380049d0’
[Jun 6 15:34:58] DEBUG[5391] channel.c: Avoiding deadlock for channel ‘0x7f4c380049d0’

I found nothing at internet
So i decided to upgrade to asterisk 1.8
The error stop showing up, but i have the same result.
When the servers stops, nothing is there in the debug.
I just can restart.

I did everything i could for detecting this problem
I have more installations with Xeon Server, and more than 50 phones and i have compare all the configs…
I have everything with switches cisco, vlan, phone cisco, digium cards.

Im lost.

Where do you think i can look?

Thanks

You have a deadlock. Firstly try updating to the very latest version. If that doesn’t help, you need to compile with thread debugging and don’t optimise options turned on. When it freezes, start a new console session and enter the command “core show locks”.

Then attach gdb and do:

bt
bt full
thread apply all bt
thread apply all bt full

Save the output. Obscure sensitive data, as little as possible. Raise a bug report on issues.asterisk.org, attaching the core show locks and gdb output. Even though the gdb output will be large, do not compress it.

Look for error messages mentioning locks.

I got lost here:

Then attach gdb and do:

bt
bt full
thread apply all bt
thread apply all bt full

That is in the console?

I did my reading.
But, the service never stops, so maybe i can just upload the core show channels and the backtrace-threads.txt
Or will asterisk give me a core file without crashing (closing)?

Thx

You can attach to the running process using:

gdb /usr/sbin/asterisk

or you can use gcore to take a dump (it basically does the above and then requests a core dump and exits.

Having debugged deadlocks myself, having the core dump is important in terms of working out how the locked threads got to where they attempted the lock.

There is actually also a better backtraces option that might be worth trying. It should give more symbolic information in the core show locks.

I did what i could.
Its here: issues.asterisk.org/jira/browse/ASTERISK-18026

But this is out of control.
Servers is going down every hour.

Maybe i should downgrade to version 1.4

What do you think?

Unfortunately the new bug tracker doesn’t allow third party comments in feedback state, but what you are being asked to do is to try the branch level development version, from the SVN repository, at svn.digium.com/svn/asterisk/branches/1.8

Well, The company decided to downgrade to 1.4
They dont trust that 1.8 will do it because its been just 15 days since the last release.

And the guy from issues i saying he believe so we cant be sure.
I think that another crash will get us into problem in this company.

So, maybe a downgrade is the smartest to do.
What do you think?

Whatever you do, could you put a link to this thread in the the issue report.

Bear in mind that, if you fallback, and the bug isn’t fixed in the development version, it probably won’t get fixed until someone else reports it and is prepared to stay the course.

I really tried, but the response is a litte slow.
I know there is a lot of work. How ever, I’m going to try the new version in a few weeks after the next version is released and see if the problem was fixed.