Hi,
I have an Asterisk 1.8 server connected to OpenIP via a Trunk SIP , the problem is that usersoften suffer from not being able to affectionately calls to mobile or fixed numbers , Asterisk on the console I get the following display:
== Using SIP RTP CoS mark 5
– Called xxxxxxxxxx@OpenIP
– SIP/OpenIP-0000069e is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
– Executing [xxxxxxxxxx@fromme:3] Hangup(“SIP/1900-0000069d”, “”) in new stack
== Spawn extension (default, xxxxxxxxxx, 3) exited non-zero on ‘SIP/1900-0000069d’
– Executing [h@fromme:1] Hangup(“SIP/1900-0000069d”, “”) in new stack
I can confirm that the number called is not busy, I’m testing on my own mobile phone. as the message is displayed almost all the time. in order to make a call one must try again to call so many times.
Here is a more detailed log: ( xxxxxxxxxx means the dialled number, yyyyyyyyyy means the callerid number)
– Executing [xxxxxxxxxx @default:1] Set(“SIP/1016-0000050f”, “CALLERID(all)=yyyyyyyyyy”) in new stack
– Executing [xxxxxxxxxx @default:2] Dial(“SIP/1016-0000050f”, "SIP/OpenIP/xxxxxxxxxx ") in new stack
== Using SIP RTP CoS mark 5
– Called OpenIP/0479885578
– SIP/OpenIP-00000510 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
– Executing [0479885578@default:3] Hangup(“SIP/1016-0000050f”, “”) in new stack
== Spawn extension (default, xxxxxxxxxx , 3) exited non-zero on ‘SIP/1016-0000050f’
– Executing [h@default:1] Hangup(“SIP/1016-0000050f”, “”) in new stack
== Spawn extension (default, h, 1) exited non-zero on ‘SIP/1016-0000050f’
That’s correct. These are for registrations and for qualify (or the other side’s equivalent). Ignore them and look for the 4xx and 5xx responses to INVITEs.
Any 4xx or 5xx response is a failure. Most of those will be mapped to congestion.
You need to look at them and decide:
whether they are a correct reason for the call failing;
whether there are any that are unreasonable, and where they suggest the problem lies.
The list of standard SIP status codes is in the SIP RFC. Googling “SIP RFC” should find that.
Until you identify the unexplained failure codes, there is rather little that one can do to suggest solutions.
This is where they are decoded into ${HANGUPCAUSE} values, which will give you some idea of the possibilities:
switch(cause) {
case 401: /* Unauthorized */
return AST_CAUSE_CALL_REJECTED;
case 403: /* Not found */
return AST_CAUSE_CALL_REJECTED;
case 404: /* Not found */
return AST_CAUSE_UNALLOCATED;
case 405: /* Method not allowed */
return AST_CAUSE_INTERWORKING;
case 407: /* Proxy authentication required */
return AST_CAUSE_CALL_REJECTED;
case 408: /* No reaction */
return AST_CAUSE_NO_USER_RESPONSE;
case 409: /* Conflict */
return AST_CAUSE_NORMAL_TEMPORARY_FAILURE;
case 410: /* Gone */
return AST_CAUSE_UNALLOCATED;
case 411: /* Length required */
return AST_CAUSE_INTERWORKING;
case 413: /* Request entity too large */
return AST_CAUSE_INTERWORKING;
case 414: /* Request URI too large */
return AST_CAUSE_INTERWORKING;
case 415: /* Unsupported media type */
return AST_CAUSE_INTERWORKING;
case 420: /* Bad extension */
return AST_CAUSE_NO_ROUTE_DESTINATION;
case 480: /* No answer */
return AST_CAUSE_NO_ANSWER;
case 481: /* No answer */
return AST_CAUSE_INTERWORKING;
case 482: /* Loop detected */
return AST_CAUSE_INTERWORKING;
case 483: /* Too many hops */
return AST_CAUSE_NO_ANSWER;
case 484: /* Address incomplete */
return AST_CAUSE_INVALID_NUMBER_FORMAT;
case 485: /* Ambiguous */
return AST_CAUSE_UNALLOCATED;
case 486: /* Busy everywhere */
return AST_CAUSE_BUSY;
case 487: /* Request terminated */
return AST_CAUSE_INTERWORKING;
case 488: /* No codecs approved */
return AST_CAUSE_BEARERCAPABILITY_NOTAVAIL;
case 491: /* Request pending */
return AST_CAUSE_INTERWORKING;
case 493: /* Undecipherable */
return AST_CAUSE_INTERWORKING;
case 500: /* Server internal failure */
return AST_CAUSE_FAILURE;
case 501: /* Call rejected */
return AST_CAUSE_FACILITY_REJECTED;
case 502:
return AST_CAUSE_DESTINATION_OUT_OF_ORDER;
case 503: /* Service unavailable */
return AST_CAUSE_CONGESTION;
case 504: /* Gateway timeout */
return AST_CAUSE_RECOVERY_ON_TIMER_EXPIRE;
case 505: /* SIP version not supported */
return AST_CAUSE_INTERWORKING;
case 600: /* Busy everywhere */
return AST_CAUSE_USER_BUSY;
case 603: /* Decline */
return AST_CAUSE_CALL_REJECTED;
case 604: /* Does not exist anywhere */
return AST_CAUSE_UNALLOCATED;
case 606: /* Not acceptable */
return AST_CAUSE_BEARERCAPABILITY_NOTAVAIL;
default:
return AST_CAUSE_NORMAL;
My problem is solved
I told you that we use 10 channels for inbound and outbound calls simultaneously with the operator OpenIP, So We have updated the number of channels and increase up to 30 and the problem is solved
—channels is the number of incoming and outgoing calls simultaneously—
Was monitoring this as it went on and one thing that I can suggest for anyone in the future reading this is to ask for a utilization report anytime you feel you may be reaching maximum sessions. Often your sip provider should be able to provide this for you.
