[SOLVED] Odd SIP Issue - "182 Queued"

[danplacek]

We had a customer yesterday who stopped recevinging incoming calls.

The issue was fixed by a reboot, and unfortunately I did not keep a copy of the logs.

However, what seemed to be happening is that incoming SIP INVITE's were getting a "182 Queued" message back instead of "180 Ringing" as expected, so when you called you did not hear any ringback, and the call never went through... even this it was "connected".

Anyone have any insight into how this could happen or what that particular status code means?

Thanks.

Message was edited by: Daniel Placek

[juliomar]

Hi Daniel,

The UC320W will respond with a 182 Queued message when the internal target has reached its inbound call limit.  This will clear up once a call is terminated and a slot is open.  In this case I think we should try to understand if there were that many calls coming in to the internal target, or were the calls that were finished not being released.

Please monitor and send us any logs if the same situation occurs so that we can see which case is occurring.

Cheers,

Julio

[danplacek]

At the time there were 0 calls. They were unable to make outgoing calls, and incoming calls never rang through and just got silence. (presumably because they were waiting in "queue")

As mentioned, a reboot fixed the issue and it has yet to reoccur.

This hs been a more or less stable install for several months now, so I am unsure what the trigger was.

We will be sure to save logs if it happens again.

[danplacek]

This happened again at a different customer site. Unforunately getting it fixed was time critical so we reset the UC320 right away. I did however snag a SIP trace before doing so. As with last time, no one was using the phones -- this is a low call volume customer.

Has anyone else encountered this? Or are we just lucky?

May 30 13:27:25 UC320W user.debug voice: INVITE sip:414226xxxx@64.179.xxx.xxx:5060;transport=udp SIP/2.0

From: "MUNGER TECH"<414332XXXX>;tag=10.152.0.13+1+158e12+ff647c9d;isup-oli=00

To: <414226XXXX>

Call-ID: 224D8B87@10.152.0.13

CSeq: 596723459 INVITE

Via: SIP/2.0/UDP 64.179.xxx.xxx:5060;branch=z9hG4bK-963-B68D2136-fc2dc5993f859e4386827053ba7a9f33

Route: <64.179.XXX.XXX>

Record-Route: <64.179.XXX.XXX>

Via: SIP/2.0/UDP 64.179.xxx.xx:5060;branch=z9hG4bKp98tgl009gp0ktgnk6i1.1

Allow-Events: message-summary,refer,dialog,line-seize,presence,call-info,as-feature-event

Max-Forwards: 69

Organization: MetaSwitch

Supported: 100rel

Supported: resource-priority

P-Asserted-Identity: "MUNGER TECH" <414332XXXX>

Expires: 180

Contact: "MUNGER TECH"<4143322701>;isup-oli=00

Content-Type: application/sdp

Content-Length: 192

v=0

o=- 2667615687 2667615687 IN IP4 64.179.xxx.xx

s=-

c=IN IP4 64.179.xxx.xx

t=0 0

m=audio 27240 RTP/AVP 0 101

a=rtpmap:101 telephone-event/8000

a=ptime:20

a=silenceSupp:off - - - -

May 30 13:27:25 UC320W user.debug voice: SIP/2.0 182 Queued

To: <414226XXXX>

From: "MUNGER TECH"<414332XXXX>;tag=10.152.0.13+1+158e12+ff647c9d;isup-oli=00

Call-ID: 224D8B87@10.152.0.13

CSeq: 596723459 INVITE

Via: SIP/2.0/UDP 64.179.xxx.xxx:5060;branch=z9hG4bK-963-B68D2136-fc2dc5993f859e4386827053ba7a9f33

Via: SIP/2.0/UDP 64.179.xxx.xx:5060;branch=z9hG4bKp98tgl009gp0ktgnk6i1.1

Record-Route: <64.179.XXX.XXX>

Server: Cisco/UC320W-2.2.2(1)

Allow-Events: talk, hold, conference, x-spa-cti

Content-Length: 0

[Christopher Edgeworth]

Hi Daniel,

Is the target inbound destination the AA by chance?

Chris

[danplacek]

Yes it is.

[Christopher Edgeworth]

You might take a look at the new 2.2.3 Limited Deployment release which contains several AA fixes...

[danplacek]

None of those fixes seem to resemble this issue. Was there one in particular that caught your eye?

[Christopher Edgeworth]

Fixed an intermittent issue in which the AA did not answer inbound FXO calls. (CSCty62404).  The issue was reported on FXO but I believe the issue was a resource leak consuming AA resources, which might cause the queue messages you are seeing.

[danplacek]

Thanks Chris.

If it happens again we will give the LD firmware a try.

[danplacek]

This happened again (we have not upgraded the firmware yet).

The odd thing is -- we had changed the call routing so that a phone range before going to the AA.

Incoming Call -> Reception -> AA

Would the bug you referred to still apply in this case?

Also worth noting... the "External Trunks" page show's 0 calls when this is happening.

So not only was no one using the phone... but the system itself wasn't registering that there were any calls.

[Christopher Edgeworth]

Hi Daniel,

If the system is still in this state, please enable logs for your incoming trunks (Status -> Support Tools -> Logs) and make an incoming call that reproduces the problem.  Then please open a case with the SBSC so we can take a look at the logs and your configuration.

Thanks,

Chris

[danplacek]

Chris:

Unfortunately it is not still in this state, we rebooted.

I understand that this is frustrating in terms of troubleshooting, but this has become a REALLY big sore point with the customer; we simply cannot have their phone service down for any length of time. (Part of the problem is that this is not the only bug this customer has encountered, so they are already tired of "troubleshooting"; the UC320 currently installed is actually already a RMA unit...)

Do you recommend upgrading to the LDR at this time?

Also, if you want to let me know *exactly* what you want collected and done when this happens, I can be ready to do so quickly next time this happens (before we restart). Is there anything besides a log of an incoming call that you would want?

Thanks for the quick responses.

[Christopher Edgeworth]

Hi Daniel,

We haven't seen any complaints on the new LD release.  I think you are pretty safe to go ahead and upgrade.  If you want to PM me the case number of the other problem they are having, I'll make sure we are getting timely forward progress on it. 

For this specific issue, please enable logs and enable them on each of your inbound trunks now.

(Status -> Support Tools -> Logs).  Then when the problem occurs, please make an inbound call to the AA.  Go to the Logs page (CTRL A to select All.  CTRL C to copy), paste them in a text document.  Next, select Services -> Feedback -> Report Problems and put FOR CHRIS EDGEWORTH in the text space.  This will give us additional system status and configuation information.

Chris

[danplacek]

Chris:

We had this issue occur again on the latest LD firmware.

I have submitted case feedback/logs to you as well via email.

Thanks.