SIP 182 QUEUED Message


I really do need some help and have tried as much as i possibly can before coming here… and i am now stumpped.

Basically , i need to be able to receive the SIP Message 182 which is presented when a caller is Queued or on a second line etc.

So far I have tried installing Trixbox (<---- starting not to like this one now), Asterisk, Asterisk 1.8.0-Beta2 and with each version i only see the SIP Message 180 (RINGING), when i believe that i should be seeing the SIP Message 182 (QUEUED). I have taken on something big, because i am very experienced with windows but slowly getting better on Linux. So you can imagine my learning curve when i had to dig through everything to successfully pull down and compile Asterisk via the command line.

The tests that i have been doing to prove if the message was being generated was:

  1. Create a Queue and an Extension and from the extension simply ring the Queue that allows callers to join when no agents are present
  2. Create 2 Extensions and make one outgoing call (or go off-hook) and make an inbound call to that same phone so it takes up the 2nd line.
    With the above tests i have been running SIP Debug from the Asterisk CLI.

To start with i was only creating the Queue and calling that, but when i read an older issue on the Bug-Tracker i saw how the developer perform the test.
Here —>
(0017816: Asterisk handles 182 Queued event as 180 Ringing)

I dont know if this is truely fixed as it said that the thread has been suspended, through lack of response. But i would gladly help in some testing to verify if it works and to get me the SIP Messaging that i need.

Is anyone able to contribute anything to help me understand why i am not able to generate SIP 182 Messages.



You appear to be requesting a new feature. You either need to propose it on the developer list or submit patches against the trunk SVN version to achieve it. Asterisk does not have an internal event to signal queued and maps 182, when inbound, into AST_CONTROL_RINGING (or possibly AST_CONTROL_PROGRESS, if there is SDP).

Suspended due to lack of response means that the person who submitted the bug report was asked for more information, in this case whether it was common to signal something like queued on ISDN networks, and failed to reply. No work will be be being done if it is “suspended due to lack of response”. If you can answer the question, and it is supportive of your case, you can request the issue to be re-opened, by using the developer IRC channel or mailing list.