CHANUNAVAIL is sometimes happend on a trunks

Hi guys!
I have some problems with calling to clients from our CRM system!
Sometimes 1-2 times a day i start getting status CHANUNAVAIL
== Everyone is busy/congested at this time (1:0/0/1)
Auto fallthrough, channel ‘SIP/1012-00000b27’ status is ‘CHANUNAVAIL’
and i need to make sip reload - is it possible to fix somehow?
Thanks in advance!!

it will only reload the sip configuration, if channel is unavalable verify the peer is registered,

sip show peer to verify if is reachable will be a good start

Also, if you set a suitable logging level there should be a message earlier in the log saying why Asterisk thinks the channel is unavailable.

everything is reachable - status is OK

you mean sip set debug on? i will get logs on monday only

I actually meant core set verbose 5, and possibly also turning on debug levels and enabling debut logging.

any ideas why sip reload makes back it to work ?

Hi guys!
i get this then phone can’t call - is it enought?

  • <— SIP read from UDP:###.###.###.###:5060 —>
  • SIP/2.0 403 Forbidden
  • Via: SIP/2.0/UDP ###.###.###.### ;rport=8082;received= ###.###.###.###;branch=z9hG4bK5383e2bd
  • From: “User 1001” sip:#########@########:8082;tag=as78729647
  • To: sip:+#########@#########;tag=mavodi-1-110-d-7-0-_525400FEA482-163f-bab4d700-48a17-5ed4b090-900c4
  • Call-ID: 18790b0703a90c9558596a8233f0d7fa@#########
  • CSeq: 102 INVITE
  • Warning: 127 mskfixuagc01.msk.ims.mnc099.mcc250.3gppnetwork.org “Service not authorised”
  • Server: Mavenir UAG/v1.0 PCSCF/v1.0-14042501o
  • P-Debug-Info: “IPclSm.cpp,549,1-274-3182-7-14052764:-1,Service not authorised,Service not authorised”
  • Content-Length: 0

Based on an (UNFORTUNATELY TOO) old version of the code, this will produce CONGESTION, not CHANUNAVAIL. It will also produce a warning message, and if you don’t have your logging configured so that you saw that message, you should fix that. (A common mistake is to try and rely on screen scraping the console, rather than properly enabling log files and using those.)

It should only affect the one call attempt.

I suspect you will find that a re-registration is failing. I’m wondering if you have had your IP address changed under foot.

Otherwise you need to ask your ITSP why they are rejecting your call.

This is the, old, handler for 403 to an INVITE:

	case 403: /* Forbidden */
		/* First we ACK */
		xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
		ast_log(LOG_WARNING, "Received response: \"Forbidden\" from '%s'\n", get_header(&p->initreq, "From"));
		if (!req->ignore && p->owner)
			ast_queue_control(p->owner, AST_CONTROL_CONGESTION);
		p->needdestroy = 1;
		sip_alreadygone(p);
		break;

logs are telling you clear the reason why call is failing

The problem is that a 403 will cause CONGESTION, not CHANUNAVAIL, and will only affect the call for which they are issued.

WAS BASED ON TOO OLD A VERSION.

Based on this piece of code yes

I looked at a later version of the code, and it does look like you will get CHANUNAVAIL.

The problem with chan_sip is that is too large to view easily online, so I tend to look at older copies that I have locally.

The code that sends CONTROL_CONGESTION is gone, and handle_cause, in app_dial, defaults to chanunavaiable for all but a small number of causes.

If all the calls are faulting in the same way, I’d assume the registration is no longer valid. One possible reason is that the ISP has undermined the IP address, but the OP really needs to ask the ITSP why the INVITE is being rejected.

Thanks - am i need to place hook or not? what are you think?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.