Dale,
There are some complications -- An INVITE must be accepted or rejected
within about 32 seconds, so if a call is queued for about 30 seconds, the
manager should reject it with 486 Busy. The caller's callback-on-busy
function will then wait for a SUBSCRIBE to the phone to again indicate that
it is not busy, and send another INVITE.
Just a comment: The above is not entirely correct. Upon receiving the 182 Queued response the caller's client transaction moves to the PROCEEDING state, in which any timer B (timeout timer, set to 32 seconds by default) is ignored. So a response must be sent back within 32 seconds, but the final decision to accept the call can be postponed indefinitely
The text providing an example in RFC3261 for 182 Queued talks about 'expecting waiting time: 15 minutes', so it is foreseen that the caller can stay in this state for quite a while. No need for the incoming call manager to reject it (although it should be prepared to receive a BYE if the caller is fed up with waiting)
Jeroen
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
