Subject: [SIP] INVITE timeout in a gateway queue

From: "farhan" <[email-masked]>
Date: Sat, 2 Sep 2000 23:45:06 +0530

the response code 182 is generated when your call is in the queue.
182 is a provisional response. this means that the 182 response is not final
and hence, INVITE is retransmitted until a final response is received.

it is quite normal to have nearly 15-20 callers waiting to call on some of
our gateway deployments. For instance, our gateway at Hyderabad, India is
the only gateway for a city of 5 million people. In such a case what should
be the behaviour of the UAS as well as UAC ?
Please do remember that an average phone call is of 3 minutes. The very idea
of a queue makes sense only when we can have atleast 2 callers in the queue
(otherwise it is a trivial case of just a call-waiting). Thus, an invite
should be capable of being 'alive' for as long as the queue times 3 minutes.
how is this achieved?

1. the UAC will keep re-transmitting INVITEs and keep getting back 182
reponse code. After a minute, the UAC could erroneously time-out. Thus, is
it implicit that as long as the provisional responses are coming in from the
UAS, we keep the UAC 'alive' with the INVITE request?
2. Upon receiving a 182 response, can or should the UAC stop retranmitting
INVITEs? The UAS will, in anycase keep transmitting the final response until
an ACK or timeout.
3. Suppose, a particular call is n callers away in the queue. Each time a
call finishes, we can generate a new queue message. This queue message has
to be sent to all the other callers in the queue with their latest position
in the queue. How do we handle out of order queue messages? How do we (and
should we) reliably deliver the queue updation messages to all the UACs in
the queue ?

how does a reference stack like sipd or that of dynamicsoft handle this?

- farhan

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Kundan Singh <[email-masked]>
Date: Sat, 2 Sep 2000 15:40:40 -0400 (EDT)

> and hence, INVITE is retransmitted until a final response is received.

No.
INVITE retransmission stops after you receive a provisional 
response. This is different from other methods.
Read 10.5.1 of 2543bis.