"all circuits are busy" - Internal Sever Error

Answered Question
Dec 15th, 2009

I am trying to figure out a recent problem. I have one SIP trunk.

If I am on the phone and a call comes in I get a the message "all circuits are busy" (not from my uc500)

Any and all responses appreciated.

Here is the message detail:

UC520#debug ccsip messages
SIP Call messages tracing is enabled
UC520#term mon
UC520#
Dec 15 22:05:22.658: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Record-Route: <sip:216.82.224.202;lr;ftag=VPSF506071629460>
Record-Route: <sip:67.231.8.93;lr=on;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0
Via: SIP/2.0/UDP 67.231.8.93;branch=z9hG4bK68c.9def0604.1
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256706239266
From: "Unavailable"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
Max-Forwards: 67
Content-Type: application/sdp
Content-Length: 171
Remote-Party-ID: "Unavailable"    <sip:[email protected]>;party=calling;
screen=yes;privacy=off

v=0
o=- 1260914667 1260914668 IN IP4 63.215.28.37
s=-
c=IN IP4 63.215.28.37
t=0 0
m=audio 60658 RTP/AVP 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Dec 15 22:05:22.666: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 580 Precondition Failed
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0,SIP/2.0/UDP 67.231.
8.93;branch=z9hG4bK68c.9def0604.1,SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK50
6071629460-1256706239266
From: "Unavailable"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>;tag=68A8C05C-1E27
Date: Tue, 15 Dec 2009 22:05:22 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow-Events: telephone-event
Content-Length: 0


Dec 15 22:05:22.762: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 580 Precondition Failed
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0,SIP/2.0/UDP 67.231.
8.93;branch=z9hG4bK68c.9def0604.1,SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK50
6071629460-1256706239266
From: "Unavailable"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>;tag=68A8C05C-1E27
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0

Dec 15 22:05:22.794: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0
From: "Unavailable"  <sip:[email protected]>;tag=VPSF506071629460
Call-ID: [email protected]
To: <sip:[email protected]:5060>;tag=68A8C05C-1E27
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

Dec 15 22:05:22.818: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Record-Route: <sip:216.82.225.202;lr;ftag=VPSF506071629460>
Record-Route: <sip:67.231.8.93;lr=on;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.4deb5902.0
Via: SIP/2.0/UDP 67.231.8.93;branch=z9hG4bK68c.9def0604.2
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256706239266
From: "BOISE        ID"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
Max-Forwards: 67
Content-Type: application/sdp
Content-Length: 171

v=0
o=- 1260914667 1260914668 IN IP4 63.215.28.37
s=-
c=IN IP4 63.215.28.37
t=0 0
m=audio 60658 RTP/AVP 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Dec 15 22:05:22.826: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 580 Precondition Failed
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.4deb5902.0,SIP/2.0/UDP 67.231.
8.93;branch=z9hG4bK68c.9def0604.2,SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK50
6071629460-1256706239266
From: "BOISE        ID"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>;tag=68A8C0FC-1661
Date: Tue, 15 Dec 2009 22:05:22 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 INVITE
Allow-Events: telephone-event
Content-Length: 0


Dec 15 22:05:22.826: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Record-Route: <sip:216.82.225.202;lr;ftag=VPSF506071629460>
Record-Route: <sip:67.231.8.93;lr=on;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.5deb5902.0
Via: SIP/2.0/UDP 67.231.8.93;branch=z9hG4bK68c.9def0604.3
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256706239266
From: "BOISE        ID"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060;transport=udp>
Max-Forwards: 67
Content-Type: application/sdp
Content-Length: 171

v=0
o=- 1260914667 1260914668 IN IP4 63.215.28.37
s=-
c=IN IP4 63.215.28.37
t=0 0
m=audio 60658 RTP/AVP 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Dec 15 22:05:22.830: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 482 Loop Detected
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.5deb5902.0,SIP/2.0/UDP 67.231.
8.93;branch=z9hG4bK68c.9def0604.3,SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK50
6071629460-1256706239266
From: "BOISE        ID"  <sip:[email protected]>;tag=VPSF506071629460
To: <sip:[email protected]:5060>;tag=68A8C0FC-1661
Call-ID: [email protected]
CSeq: 1 INVITE
Reason: Q.850;cause=127
Content-Length: 0

Dec 15 22:05:22.886: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0
From: "Unavailable"  <sip:[email protected]>;tag=VPSF506071629460
Call-ID: [email protected]
To: <sip:[email protected]:5060>;tag=68A8C05C-1E27
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

Dec 15 22:05:22.918: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.4deb5902.0
From: "BOISE        ID"  <sip:[email protected]>;tag=VPSF506071629460
Call-ID: [email protected]
To: <sip:[email protected]:5060>;tag=68A8C0FC-1661
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Bandwidth.com TRM (gold.13)
Content-Length: 0

Dec 15 22:05:22.942: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.5deb5902.0
From: "BOISE        ID"  <sip:[email protected]>;tag=VPSF506071629460
Call-ID: [email protected]
To: <sip:[email protected]:5060>;tag=68A8C0FC-1661
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Bandwidth.com TRM (gold.13)
Content-Length: 0

I have this problem too.
0 votes
Correct Answer by Steven Smith about 6 years 11 months ago

Is your service provider restricting the amount of calls that you have of the SIP trunk?  The one call that you are allowing on the screen shot that you sent tells the UC500 not to allow more than one call.  So when the second call comes in, you get the 580 error.  If you change this to 2, you should see the problem occurring with more than 2 calls.  If you make the change, I think you will see what I am talking about.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Steven Smith Tue, 12/15/2009 - 14:12

Did you configure the system with CCA?  Do you have a max number of calls configured?  I believe this is a call threshold error.  Can you post your config?

mcastrigno Tue, 12/15/2009 - 15:00

I try to use CCA but it does not do so many things

I have attached my config and a screen shot from CCA that shows what I think you are asking about

thanks

Steven Smith Tue, 12/15/2009 - 15:04

Change the max number of calls to 5 on that page, or something that represents your bandwidth better.  You are only allowing 1 call.

Correct Answer
Steven Smith Tue, 12/15/2009 - 15:17

Is your service provider restricting the amount of calls that you have of the SIP trunk?  The one call that you are allowing on the screen shot that you sent tells the UC500 not to allow more than one call.  So when the second call comes in, you get the 580 error.  If you change this to 2, you should see the problem occurring with more than 2 calls.  If you make the change, I think you will see what I am talking about.

mcastrigno Tue, 12/15/2009 - 15:34

OK Steven. That worked but I guess what that proves is I don't understand the service properly!

Why would they allow another call if I am only paying for one trunk?

Seems like I am getting something I did not pay for?

I am old steven. In the old days it was one trunk - one call.

Are you telling me should expect to get as many calls going as I have bandwidth?

Thanks

mcastrigno Tue, 12/15/2009 - 17:50

I guess the anser is yes for outbound and no to inbound.

If I try to make two calls I get the message:

Dec 16 01:33:02.754: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 503 Concurrency limit reached
Via: SIP/2.0/UDP 24.119.219.2:5060;branch=z9hG4bK44220AC
From: "Front Desk" ;tag=6966E01C-76E
To: ;tag=f5da119de3db22dcaa2abb8ea9fec0ce.5f78
Call-ID: [email protected]
CSeq: 101 INVITE
Server: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

mcastrigno Thu, 12/17/2009 - 11:56

A little more information available now on this.

My service provider does restrict the number of concurrent calls (i want to know who does not so I can switch to them)

However they are currently having a problem in which they are not restricting the number of inbound calls. They received a reasonable response from the uc500 in that the number of calls exceeded the number set in the configuration which was one. Their system responded "all circuits are busy" which was true. Apparently, in order for the caller to receive a busy signal the service provide must detect that I have exceeded my max concurrencey.

This begs the question:

Is there a SIP message that the router can send that says "give the caller a busy signal" and would that be a better response that the one currently presented under these conditions.

Thanks all for your responses.

Steven Smith Thu, 12/17/2009 - 12:35

Busy tone is a SIP 486 message.  Getting the UC500 to send this message in this situation, I don't know if that is possible.  It would take a lot of with in SIP profiles, and I am still not sure it would be possible to have this be sent.

Maulik Shah Sat, 12/19/2009 - 15:53

Generally, in such situations your SIP Trunk ITSP needs to convert this to the appropriate message to send upstream to the calling party (as am sure it will go through multipe networks). It would be incorrect for the UC500 to send a 486 Busy Here when the phone is not busy truly. As a side note, you could read the below document to see if it meets what your ITSP is asking for:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftcacsip.html#wp1042876

mcastrigno Tue, 12/15/2009 - 15:10

The attached is a capture of sip messages

first is a call out that works fine.

then I attempt to call in while the frist call is using the only trunk but again i get "all circuits are busy" instead of a busy signal

interesting is the SIP/2.0 580 Precondition Failed message

interesting also is some of the numbers have "+" and some don't

this problem as an occasional issue now all the time under these condtions

Steven Smith Tue, 12/15/2009 - 15:14

The call threshold reports 580.  You need to have more calls allowed to get the calls through.  Did you change that max calls number?

Actions

This Discussion

Related Content