SIP 182 Queued vs 489 Bad Event
SIP 182 (Queued) is a 1xx Provisional response, while 489 (Bad Event) is a 4xx Client Failure response. 182 indicates that the called party is temporarily unavailable but the server has decided to queue the call rather than reject it. The call will be attempted when the callee becomes available. In contrast, 489 means that the server did not understand the event package specified in the Event header of a SUBSCRIBE request.
Описание
The called party is temporarily unavailable but the server has decided to queue the call rather than reject it. The call will be attempted when the callee becomes available.
Когда вы это видите
In call center or queuing scenarios where the callee is busy but the system holds the call in a queue.
Как исправить
Wait for the call to be dequeued. If queuing is not desired, configure the server to reject calls instead of queuing them.
Описание
The server did not understand the event package specified in the Event header of a SUBSCRIBE request.
Когда вы это видите
When subscribing to an event package that the server does not support (e.g., dialog, presence, message-summary).
Как исправить
Check which event packages the server supports (OPTIONS request) and use a supported event package name.
Ключевые различия
182 is a 1xx Provisional response, while 489 is a 4xx Client Failure response.
SIP 182: The called party is temporarily unavailable but the server has decided to queue the call rather than reject it. The call will be attempted when the callee becomes available.
SIP 489: The server did not understand the event package specified in the Event header of a SUBSCRIBE request.
You encounter 182 when in call center or queuing scenarios where the callee is busy but the system holds the call in a queue.
You encounter 489 when when subscribing to an event package that the server does not support (e.g., dialog, presence, message-summary).
Когда что использовать
For 182 (Queued): Wait for the call to be dequeued. If queuing is not desired, configure the server to reject calls instead of queuing them. For 489 (Bad Event): Check which event packages the server supports (OPTIONS request) and use a supported event package name.