SIP Reliability for UDP

For UDP, SIP requests and replies are matched up using the Call-ID
header field, under the assumption that there is only one outstanding
request per call at any given time.

For requests such as OPTIONS or BYE which only return one return code,
reliability is easy to provide:  the client simply retransmits the
request until it receives a response.  Since the requests are
idempotent, the server does not know or care whether a request is a
retransmission or another request.

However, the SIP invitation requires special consideration for several
reasons:

(1) After the invitation, a considerable time may elapse before the
server can determine the outcome.  In particular, the called party may
be ``rung'' or extensive searches may be performed, so delays can reach
several tens of seconds. To indicate progress to the caller, the server
returns a 1xx informational response indicating the it is searching or
ringing the user.

If a telephony interface is modeled or if we need to interface to PSTN,
the caller will provide ringback, a signal that the callee is being
alerted.  Once the callee picks up, the caller needs to know so that it
can enable the voice path and stop ringback.  The response code from the
callee could get lost and the callee has no way of knowing this. Thus,
the caller will continue to hear ringback and the callee will think that
the call exists.

(2) The client may decide to abort the call. If TCP is used, it can
signal this by dropping the connection. With UDP, the called party would
continue to be alerted, possibly pick up and send data (``hello ...
hello?'') to an RTP port which may by then be used for a different phone
call. Thus, the calling party needs to have the ability to abort a call
attempt.

Possible solutions:

[Confirm]:

The caller sends the invitation, repeating it at fixed or increasing
intervals if there is 1xx (progress) response.  The server sends a
single indication of progress as progress changes.  Eventually, the
server returns a 200 (OK) code and requests confirmation by including a
'Confirm:  requested'.  The caller then reissues the invitation (if
still interested in the call) with a 'Confirm:  yes' or 'Confirm:  no'
header.  The callee acknowledges this second request as normal, but
without 'Confirm' header.

Messages needed: 
  C->S: 2
  S->C: 2

Solves (1):  partially, however, it's the *caller* that needs a reliable
200 code to stop ringback, but here, the callee requests confirmation. 
INVITE requests with and without Confirm:  yes/no aren't quite the same;
the confirmation doesn't need a session description

Solves (2): no, since the callee will continue to be rung after the
caller has hung up; needs a BYE request to allow the callee to terminate
the call

[Handshake]:

As in [Confirm], but the callee keeps retransmitting the 200 (OK) or
other final response code until it gets a {\sf ACK} request, which it
acks once. (The client can ignore the ack.) This is similar to making
'Confirm: requested' mandatory, but {\sf ACK} does not carry a session
description.

Messages needed: 
  C->S: 2
  S->C: 2

Solves (1): yes; this also has the advantage that a UDP-TCP proxy can
now release any transaction state since it knows that the UDP client has
received the final response (since the UDP client does not rely on a
response for {\sf ACK}, loss of the response to that request is
unimportant)

Solves (2): no, same as above

[RepeatReq]:

The caller issues an invitation; the callee periodically (every second
or so) sends a status update, until it sends one copy of the final
status code. The client repeats the invitation if it does not get a
report for more than the normal interval. Thus, if the 2xx response is
lost, the caller will reissue the INVITE and eventually get it.

Messages needed: 
  C->S: 1
  S->C: one per second of ringing (BAD)

Solves (1): yes

Solves (2): no, same as above 

[RepeatReqRes]:

Same as [RepeatReq], except that the callee expects to get periodic
"refreshes" of the invitation or it stops ringing.

Messages needed: 
  C->S: one per second of ringing (BAD)
  S->C: one per second of ringing (BAD)

Solves (1): yes

Solves (2): yes


RECOMMENDATION:

[Handshake] + BYE, since the other solutions are either antisocial (if
servers are on both ends, a failure could have a caller or callee send
packets for days on end); BYE is needed to cleanly terminate an on-going
call attempt.
