180 RINGING as call progress indication-need to take it out!


As a summary, my asterisk seems to be sending a 180 RINGING Message as a call progress indicator or something, and this is causing my sip endopoints to handle wrong the 486 BUSY HERE message when the called party phone is busy.

This is what I have:

PSTN Huwai Softswitch->Asterisk 1.2.1 -> SIP Endpoint (W7 Optics LMG)

The problem is that, when doing an outgoing call to the PSTN, the asterisk sends a RINGING back to the SIP Endpoint without even get yet any answer from the PSTN Softswitch… see this:


SIP Endpoint to Asterisk SIP/SDP Request: INVITE
Asterisk to SIP Endpoint SIP Status: 100 Trying
Asterisk to PSTN Softswitch SIP/SDP Request: INVITE
Asterisk to SIP Endpoint SIP Status: 180 Ringing
PSTN Softswitch to Asterisk SIP Status: 100 Trying
PSTN Softswitch to Asterisk SIP Status: 486 Busy Here
Asterisk to PSTN Softswitch SIP Request: ACK
Asterisk to SIP Endpoint SIP Status: 486 Busy here
SIP Endpoint to Asterisk SIP Request: ACK

If you see, at message 4 the Asterisk sends a 180 Ringing to the SIP Endpoint without even knowing if the call will be completed, busy, not found, service unavailable or whatever it can be. This is causing an early RINGING TONE at the SIP endpoint caller that doesn’t change when at the end the call was BUSY and then the caller gets confused because the phone rings and rings and the call is actually busy!

My sip endpoint is not able to understand the final 486 BUSY HERE (even that it acks the message) and then it just drop the call. I have checked with the vendor and this happen because having a ringing and then a busy on the same call represents a violation of the sip protocol. (not a problem on the endpoint)

I need to find a way to take out that early 180 RINGING, which i guess the asterisk uses as a “calling progress” attempt or something like that.

Please let me know what do you think!



If I’m not mistaken, the behavior is compliant to the SIP code. You could look it up in the spec and if not, post it as a bug to digium, but I do think it is compliant and as a result, your endpoint may not be responding properly to the 486 Busy Here.



Thanks for your answer. During the weekend i did some testing with my other SIP Equipment, and this is what i found out:

I replace the Asterisk Server with a NexTone MSW Box, i did exactly the same setup and with the NexTone, the Busy Tone worked fine, the SIP endpoint was exactly the same.

When i looked at the traces, that 180 RINGING, was not in the trace (Message 4 in previous trace) and the endpoint handled properly the 486 Busy Here message.

Also, i tried with Asterisk@Home 1.1.09 and the problem was replicated.

Any thought?



Whats your dialplan like?

are you using Dial(tech/number,r) ;**note the r for ringing?

Hey swk,

My dial plan looks like this:

exten => _XXXXXXXX,1,Dial(SIP/332948${EXTEN}@bestel)
exten => _0.,1,Dial(SIP/332948${EXTEN}@bestel)
exten => _0.,1,Dial(SIP/332948${EXTEN}@bestel)

I guess no “r”…

What do you think?

interesting… if you couple post a sip debug of the 2 sip endpoints for us to look at this would be a good thing…

Also as the othe poster said a 486 after the 180 ringing should still be ok…


you will find vendors ‘all over the map’ in their implementations of SIP. Also - as I recall, I think the specs/protocol is pretty loose here, meaning that one device may send the ringing followed by the busy here message and the other may wait to actually determine if it is busy before sending any feedback, and both are compliant (I think). That is why it is important to do a lot of testing on equipment if you are going to do any mass rollout - and make sure everyone talks to each other properly…


I know this and you know this, I just dont recall seeing asterisk actually send a 180 (or a 183) out of order like this when beng used strictly as a SIP b2bua



Well, finally i gues you were right, there was an “r” at the end of some lines which were causing that 180 RINGING message.

We took it out and now its working, now my only concern is that we have a PDD of 14 secs before the call is “completed” and we got a busy signal.

I’ll check how we can improve this time.

For normal calls, with normal ringing, PDD is about 5-7 seconds.

Any idea?