Subject: Retransmission of INVITEs after receiving provisional response

From: Anup Rao <[email-masked]>
Date: Wed, 19 May 1999 14:39:29 -0700

If a UAC sends an INVITE, and gets back a provisional response, it
should stop retransmitting the INVITE request(Section 10.5.1 of the SIP
RFC).

If the UAS now dies, the UAC would need to timeout eventually since a
final response is not forthcoming. What is the expected behavior of the
UAC to check with the UAS in this case - resend the INVITE with a new
CSeq if it has not received a final response in a certain interval ?

(In draft-11 or earlier, the UAC retransmitted the INVITE with a larger
interval after receiving the provisional until it received the final -
so this wasnt an issue.)

Thanks
Anup Rao.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 May 1999 20:54:10 -0400

> CSeq if it has not received a final response in a certain interval ?

There is really no standardized behavior here. This UAS failure appears
exactly the same as a UAS which never responds because the called party
never answers the phone. How long the UAC waits its at the discretion of
the UAC. What it does when it gives up is also up to the UAC. A
reasonable choice is to send a CANCEL. Since the UAS received a 100
(probably from a local proxy), the local proxy will receive and respond
to the CANCEL with a 200, and then the UAC can do whatever it wants. It
can try again, or call someone else, or whatever. 

Resending the INVITE with a new CSeq but the same Call-ID is probably
not a good idea. If the UAS has not died, but just not had the user
answer yet, it will receive a second INVITE for the same call before
answering the first. This is a confusing situation; you should generally
not send another INVITE before the previous has been answered.
Otherwise, the UAS has to queue all these requests up, make sure they're
ordered, and then answer them all once it knows whether the call is
accepted or not. Quite messy. I think the spec says somewhere you
shouldn't do this; if not, it needs to be clarified.

> interval after receiving the provisional until it received the final -

This was removed since the interval was so large (30s), that in general
users will have given up anyway before retransmitting an INVITE.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen