Bug with chan_sip and DIALSTATUS in versions above 11

Asterisk Asterisk SIP
1

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

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…

2

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`):

		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.

1 Like
3

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?

=========================================================================
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>