Subject: SIP reliability

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Wed, 23 Jul 1997 15:34:58 -0400

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 reply. 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: 2 C->S, 2 S->C
Solves (1):  partially, however, it's the *caller* that needs a reliable
200 code to stop ringback, but here, the callee requests confirmation.

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 'CONFIRMED' request, which it
acks once. (The client can ignore the ack.) This is similar to making
'Confirm: requested' mandatory, but CONFIRM 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 CONFIRMED, 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
robots are on one or 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.

Comments and other suggestions are welcome. Since this is required for
interoperability, I'd like to get this right for the next revision of
the draft, due out be week's end.

Thanks.

Henning

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 908 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Pete Cordell <[email-masked]>
Date: Fri, 1 Aug 1997 16:11:18 +0100

Henning and Mark,

Wow, I thought you guys would still be asleep!!!

Henning, It's interesting that you say that RTCP is useless for
membership control.  I must have been talking to the wrong people! 
Although you say there are other non-RTP protocols that are being used,
I think that the principles could be applied to other non-RTP payloads.
I also don't think that SIP really needs to know when remote parties are
connected.  I thought SIP's job was to get in, do the inviting and get
out.  The rest is up to the media agents themselves.  If they don't
report into some central authority that's fine.  All I'm advocating is
that the original session termination mechanism be used to end an
aborted session.

Mark, I'm comforted by the fact that you say SIP is no more complicated
than it ever was.  However, I look at the weight of paper and think
'complex', or at least more complex than before.  I'm also wary of
protocols that have minimal implementations with lots of optional
features.  In terms of using the protocol in anything other the original
test scenarios the various combinatorial relationships of various levels
of support become very difficult to work out.  In the long run its
probably better to make the whole lot mandatory.

I guess my gut feeling is that the feature creep is not complete.  BYE
has been added (I infer) and then what else?  It just seems the
beginning of a slippery slope.

What IP is really good for (among other things) is large multicast
sessions.  SDP covers off most of this well, and I guess RTSP will soon
be operating in this space.  What these two don't allow is getting a
specific person into a conference.  I would like to see something that
was light and did this really well, wrapping up the whole area nicely. 
If SIP is not the thing for that, perhaps something should be developed.

Thanks for your comments anyway,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: [email-masked]
Tel: +44 1473 646436
Fax: +44 1473 643791
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British Telecommunications plc.
=================================