Showing results for 
Search instead for 
Did you mean: 

Get the latest new and information the November issue of the Cisco Small Business Monthly Newsletter


Re: Odd SIP Issue - "182 Queued"


We have found an interesting CDR record that shows up right before the system locks up and stops accepting calls.

Below are 2 screenshots from the last 2 times it happened.

An incoming call with unknown CLID/CNAM comes in... following that the system accepts no further calls.



Odd SIP Issue - "182 Queued"

Mystery solved.

It appears to be a security problem on our SIP providers end. We did a long running packet capture in between the UC320 and the provider IAD.

Immediately preceding this issue we found:

INVITE sip:9011441212790843@64.179.x.x, with session description

INVITE sip:8011441212790841@64.179.x.x, with session description

INVITE sip:1#011441212790840@64.179.x.x, with session description

There were many calls in a row like this -- it appears to be attempted toll fraud.

The UC320 appears to accept the first 12 calls, then spits back "182 Queued" to all the rest that come in.

Because we had the AA setup to "Return to Main Menu" on timeout (instead of endcall) and the person sending these bogus requests was not sending "BYE"'s, the calls got hung, and any further calls got "Queued".

We are going to work with the provider on this... but it sure would be really nice if you could setup a UC320 to reject any calls to DIDs not defined in the incoming dial plan.

Thanks for all of your assistance.

Cisco Employee

[SOLVED] Odd SIP Issue - "182 Queued"


Thank you for the update on this outstanding item. 

One question, was the source IP address of the inbound calls from your SIP provider? The UC320W does block inbound calls from IP addresses that are not registered via the configured SIP trunk.  (There are some corner cases where we generated some PMF's to allow inbound calls on multiple IP's).

Thanks again for your update.



[SOLVED] Odd SIP Issue - "182 Queued"

Yes they were sourced from the provider -- that's why I identified it as a provider security problem.

It is SIP delivered over a T1 with QOS; they have a AdTran IAD on site as an SBC... it clearly has some access list problems.