Subject: Re: SIP reliability

From: Pete Cordell <[email-masked]>
Date: Fri, 1 Aug 1997 13:46:20 +0100

I'm alarmed at the ever increasing size of SIP.  My original
understanding of what SIP was intended to do was in invite users to
sessions as an adjunct to SDP.  Even if this is not its sole purpose, it
serves a very useful function in this role.  As SDP is elegantly simple,
SIP should be also.  The recently proposed changes seem to be moving
away from this.  

If you bear with me I'll explain why I think the functionality you
desire can be achieved using much simpler signalling (Maybe you'll only
get 80% of the signalling options, but that will be achieved with 20% of
the coding effort).  

SIP, to me, fills the need for a directed SDP announcement, i.e. person
x can explicitly invite person y to an SDP style session.  In the
limiting case y might not be in the session because there was never an
SDP announcement (i.e. its a point-to-point call).  Alternatively x
might be trying to get y's advice while in a previously announced
conference.

Therefore, the important aspect of SIP should be the reliable delivery
of an SDP announcement to y.  

The basic stages in just about all call invitation protocols are:

make call	- equivalent to INVITE in SIP
ringing		- equivalent to 150 Ringing in SIP
user connected	- equivalent to 200 OK in SIP

Where SIP seems to be having problems is in getting the 200 OK response
back to the caller in a reliable way after a long ringing delay.  The
confirm field breaks the attractive HTTP model, and its optional status
makes predicting the outcome of various scenarios difficult.  

However, on a connectionless network we can make use of media arrival to
signal user connected.  I guess you will have discussed this, but I have
thought it through and can see no problems with the principle.  Perhaps
I've had some beginner's luck that has enabled me to see some things
that the experts have missed, so bear with me a while.

So: I suggest changing the 200 OK reason to mean invitation delivered
rather than connected.  This makes the initial transaction simple.  It
is easy to make reliable on UDP, and it is stateless.  All the redirects
can still apply (although a simple implementation could decide to cave
at that point), as can the negotiations.

The connected status can be indicated using RTP as follows:

The sending terminal can start sending RTP/RTCP packets as soon as the
200 OK response (invitation delivered) is received (if it is not already
doing so as part of an on going session).  (If no others are in the
call, it probably just wants to send RTCP.  This would be equivalent to
silence suppression when no RTP packets are sent.)  Likewise the
receiving terminal can subscribe to the multicast group straight away
and pull in the RTCP messages.

When the receiving terminal connects it can also start sending RTP/RTCP.
 The sending terminal can use the reception of media from the receiving
terminal to un-mute its local media sources and send RTP media on to the
network (if it is not already doing so).

If the sending terminal hangs up before the call is answered, then RTCP
will send a BYE packet.  The receiving terminal can use this to
disconnect.  In the, hopefully rare, situation that the BYE packet gets
lost, the receiving terminal can timeout in the usual way an RTP session
is ended (the remote user may also intervene to close the session).

The receiving terminal can implement do not disturb functionality by
replying with the existing 450/451 failure code to the initial
invitation.  

All the user location stuff can be used as before to deliver the initial
invitation.

This scheme is very light-weight and fits well with SDP.  It also offers
significant value when used by itself.  It's highly flexible and allows
many user location features to be used.  It exploits IP features rather
than copying connection-oriented setup protocols.  Therefore I propose
that SIP be streamlined to confirm to the call setup model described
above.

Any comments welcome,

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.
=================================

=================================
Pete Cordell
BT Labs
E-Mail: [email-masked]
Tel: +44 1473 646436
Fax: +44 1473 643791
=================================

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 01 Aug 1997 09:07:56 -0400

While I share your desire for simplicity, I disagree on a number of
assumptions you make:

- SIP can be used for sessions which are not carried over RTP, including
stand-alone applications using proprietary data protocols.

- SIP implementations in many cases (including the two on-going
implementations that I'm aware of) do not have direct access to RTCP, so
this would impose on media agents which know nothing of SIP (and
shouldn't) the burden of somehow communicating to the SIP agent that
they are getting RTCP packets.

The idea of using RTCP to indicate "connectivity" you propose would, as
far as I can tell, not significantly simplify SIP. It would remove the
CONNECTED message; that's it. 

Even making the assumption that RTCP BYE can be used to signal end of
call (dubious, due to lack of RTCP BYE reliability - RTCP BYE is sent
once): Note that the SIP BYE message cannot be replaced as you
described, since, in a unicast call, the calling side doesn't yet know
where to send the data, as the callee has to indicate port number and
destination address in its 200 response. 

Henning

---

From: Mark Handley <[email-masked]>
Date: Fri, 01 Aug 1997 10:03:12 -0400

>I'm alarmed at the ever increasing size of SIP.

One of my aims has always been to keep SIP simple.  We sacrificed some
of that simplicity by allowing both TCP and UDP, but this seemed to
all concerned to be what people want, and I still believe this was a
good decision.

Beyond that, the HTTP-style format permits many header fields which
increase the length of the document and many response codes.  This
makes SIP appear very complex, but also all of this functionality is
only detail-enhancement.  You can write a legal and reasonably
performing SIP implementation with minimal header fields and only pay
attention to the response category rather than the actual code.  We
gained one compulsory method (CONNECTED) this time round, but it
actually simplifies things because it does away with the SIPv1
confirmation mechanism.  When you strip away all the frills, my sdr
implementation of SIPv2 over UDP is not significantly more complex
than the SIPv1 implementation - just better specified!

The only necessary extension is the UDP/TCP one, and I'd rather not
stir that discussion up again.

But it seems that what we should do is write a short appendix making
it clear what a minimum useful and legal implementation would consist
of.  It's not always easy to extract this information from the rest of
the spec.

Mark