# Bug with chan\_sip and DIALSTATUS in versions above 11 **URL:** \ **Category:** Asterisk SIP\ **Created:** [March 6, 2018, 10:12am UTC](https://community.asterisk.org/t/bug-with-chan-sip-and-dialstatus-in-versions-above-11/73773 "2018-03-06T10:12:59Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ivan32](https://avatars.discourse-cdn.com/v4/letter/i/b5a626/32.png) [@ivan32](https://community.asterisk.org/u/ivan32)\ **Post date:** [March 6, 2018, 10:12am UTC](https://community.asterisk.org/t/bug-with-chan-sip-and-dialstatus-in-versions-above-11/73773/1 "2018-03-06T10:12:59Z")
Hello. Two situations on the same system, with chan\_sip compiling and with chan\_pjsip: 1. chan\_sip If i’m calling on inactive/chanunavail number (SIP 480 response), i’m getting DIALSTATUS value BUSY 2. chan\_pjsip the same call and in DIALSTATUS i have NO ANSWER as it must be, as it discribed here: [https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings](https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings) Why in first case with chan\_sip i’m getting wrong DIALSTATUS ? It looks like a bug, or i mustnt use chan\_sip in version 12 or high? I tried it on 13.18-cert2, on lastest 15 version… ---
**Author:** ![mjordan](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/mjordan/32/1509_2.png) [@mjordan](https://community.asterisk.org/u/mjordan)\ **Post date:** [March 6, 2018, 2:01pm UTC](https://community.asterisk.org/t/bug-with-chan-sip-and-dialstatus-in-versions-above-11/73773/2 "2018-03-06T14:01:12Z")
Taking a quick look at `chan_sip`, it does return `AST_CAUSE_NO_ANSWER` when it receives a `480` (which is Asterisk’s internal enum for NO ANSWER`): ```auto case 480: /* No answer */ return AST_CAUSE_NO_ANSWER; ``` So it appears to be doing the correct thing. Without seeing a lot more information, I can’t say why you’re seeing the behavior you’re seeing. Regardless, `chan_sip` is community supported, and the vast majority of development efforts are put into `chan_pjsip`. Any bugs against `chan_sip` would have to be patched and supported by the Asterisk community. Generally, I would recommend using `chan_pjsip`. ---
**Author:** ![ivan32](https://avatars.discourse-cdn.com/v4/letter/i/b5a626/32.png) [@ivan32](https://community.asterisk.org/u/ivan32)\ **Post date:** [March 7, 2018, 2:13pm UTC](https://community.asterisk.org/t/bug-with-chan-sip-and-dialstatus-in-versions-above-11/73773/3 "2018-03-07T14:13:10Z")
**mjordan** thank you for the answer. Yes, i saw chan\_sip.c and i tried to change and recompile it with different causes for “case 480”. But it takes effect only on ${HANGUPCAUSE}… And ${DIALSTATUS} still the same = BUSY… If chan\_sip still is supporting by community, i’d like to ask for help… I could provide any logs/dumps from my system, but i cant because i’m new user here. For example CLI log below. Should i provide something else? ```auto ========================================================================= Connected to Asterisk certified/13.18-cert2 currently running on localhost (pid = 1216) localhost*CLI> core set verbose 99 Console verbose was 3 and is now 99. == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 > 0x7fdd6c00d9a0 -- Strict RTP learning after remote address set to: 10.15.200.49:17698 -- Executing [89296012362@testad:1] Set("SIP/104-00000012", "CALLERID(num)=79003628244") in new stack -- Executing [89296012362@testad:2] Dial("SIP/104-00000012", "SIP/multi/79296012362,25,g") in new stack == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 -- Called SIP/multi/79296012362 -- SIP/multi-00000013 redirecting info has changed, passing it to SIP/104-00000012 > 0x7fdd8800b3b0 -- Strict RTP learning after remote address set to: 193.201.229.19:18018 -- SIP/multi-00000013 is making progress passing it to SIP/104-00000012 -- SIP/multi-00000013 is ringing > 0x7fdd6c00d9a0 -- Strict RTP switching to RTP target address 10.15.200.49:17698 as source > 0x7fdd8800b3b0 -- Strict RTP switching to RTP target address 193.201.229.19:18018 as source > 0x7fdd6c00d9a0 -- Strict RTP learning complete - Locking on source address 10.15.200.49:17698 > 0x7fdd8800b3b0 -- Strict RTP learning complete - Locking on source address 193.201.229.19:18018 -- SIP/multi-00000013 redirecting info has changed, passing it to SIP/104-00000012 -- SIP/multi-00000013 is busy == Everyone is busy/congested at this time (1:1/0/0) -- Executing [89296012362@testad:3] NoOp("SIP/104-00000012", "DIALSTATUS=BUSY | HANGUPCAUSE=19 | CDR(disposition)=BUSY | CDR(cause)=") in new stack -- Executing [89296012362@testad:4] Hangup("SIP/104-00000012", "") in new stack == Spawn extension (testad, 89296012362, 4) exited non-zero on 'SIP/104-00000012' -- Executing [h@testad:1] Set("SIP/104-00000012", "CDR(cause)=19") in new stack -- Executing [h@testad:2] NoOp("SIP/104-00000012", "DIALSTATUS=BUSY | HANGUPCAUSE=19 | CDR(disposition)=NO ANSWER | CDR(cause)=19") in new stack localhost*CLI> ```