Solved: Re: "all circuits are busy" - Internal Sever Error

mcastrigno · ‎12-15-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:+12083506322@24.119.219.2: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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
CSeq: 1 INVITE
Contact: <sip:+12088594276@4.68.250.148:5060;transport=udp>
Max-Forwards: 67
Content-Type: application/sdp
Content-Length: 171
Remote-Party-ID: "Unavailable" <sip:+12088594276@4.68.250.148>;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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>;tag=68A8C05C-1E27
Date: Tue, 15 Dec 2009 22:05:22 GMT
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>;tag=68A8C05C-1E27
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
CSeq: 1 INVITE
Content-Length: 0

Dec 15 22:05:22.794: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:+12083506322@24.119.219.2:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0
From: "Unavailable" <sip:+12088594276@4.68.250.148>;tag=VPSF506071629460
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
To: <sip:+12083506322@67.231.8.93: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:+12083506322@24.119.219.2: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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
CSeq: 1 INVITE
Contact: <sip:+12088594276@4.68.250.148: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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>;tag=68A8C0FC-1661
Date: Tue, 15 Dec 2009 22:05:22 GMT
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
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:+12083506322@24.119.219.2: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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
CSeq: 1 INVITE
Contact: <sip:+12088594276@4.68.250.148: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:+12088594276@4.68.250.148>;tag=VPSF506071629460
To: <sip:+12083506322@67.231.8.93:5060>;tag=68A8C0FC-1661
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
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:+12083506322@24.119.219.2:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK68c.70708603.0
From: "Unavailable" <sip:+12088594276@4.68.250.148>;tag=VPSF506071629460
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
To: <sip:+12083506322@67.231.8.93: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:+12083506322@24.119.219.2:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.4deb5902.0
From: "BOISE ID" <sip:+12088594276@4.68.250.148>;tag=VPSF506071629460
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
To: <sip:+12083506322@67.231.8.93: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:+12083506322@24.119.219.2:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.82.225.202;branch=z9hG4bK68c.5deb5902.0
From: "BOISE ID" <sip:+12088594276@4.68.250.148>;tag=VPSF506071629460
Call-ID: SEAMGC0320091215220427040455@209.244.62.70
To: <sip:+12083506322@67.231.8.93:5060>;tag=68A8C0FC-1661
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: Bandwidth.com TRM (gold.13)
Content-Length: 0

Steven Smith · ‎12-15-2009

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.

View solution in original post

Steven Smith · ‎12-15-2009

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 · ‎12-15-2009

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 · ‎12-15-2009

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

mcastrigno · ‎12-15-2009

I only have one trunk

how can I allow more than one call?

Steven Smith · ‎12-15-2009

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 · ‎12-15-2009

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 · ‎12-15-2009

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" <2089391066>;tag=6966E01C-76E
To: <12089395663>;tag=f5da119de3db22dcaa2abb8ea9fec0ce.5f78
Call-ID: C92CC00F-E91911DE-8A44DBE8-853CE9AE@24.119.219.2
CSeq: 101 INVITE
Server: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

Marcos Hernandez · ‎12-16-2009

This will all depend on the provider, as you are finding out.

Marcos

mcastrigno · ‎12-17-2009

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 · ‎12-17-2009

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 · ‎12-19-2009

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 · ‎12-15-2009

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 · ‎12-15-2009

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