Subject: comments/thoughts on SIP v1.0

From: [email-masked] (Ben Anderson)
Date: Tue, 26 Mar 1996 10:23:16 +0000

Hi,

these are in the context of currently building a "noddy" SIP client. We
haven't been able to explore all the issues of using SIP just yet - mostly
due to the fact that our code isn't quite complete, and also to a lack of
participants ;-)

Unfortunately I didn't get to see the LA multicast but I have seen the
minutes & slides. Apologies if the stuff below has already been covered.

A few thoughts:

1. We feel it'd be useful to have the unique id take on the form of an RTCP
CNAME. Thus:

ID=[email-masked]/3429845475

this helps immensely in cross-media bindings and local conference control
(assuming a SIP client might also be a local conference controller). As SIP
1.0 stands, you can't derive "[email-masked]" from a SIP message
unless it is a request (ie has the SDP "o" field present).

2. Use of SDP syntax: there are a number of thoughts here:

2.1 we use the third subfield of the "o" field to denote repeated requests
being sent by a client that has not received a reply, thus:
        1st send:
        o=ben 34235445 1 IN IP4 125.112.123.101
        2nd send:
        o=ben 34235445 2 IN IP4 125.112.123.101
etc. Is this the intended use? Obviously, it enables clients to ignore
requests they are processing but haven't replied to yet.

2.2 the sdp session attribute field is _extremely_ useful for designating
"user services". eg. our current client has 3 ready constructed "user
services": GLANCE, KNOCK, CONNECT. There is no difference at the media desc
level between a knock and a connect - the difference is in how the client
notifies the user.

2.3 Having said that, the use of the sdp syntax seems to enable the
description of a great variety of "user services" - something that will be
very important as different media/services/groupware apps arise in the
future. And in general we can describe most such 'services' without
recourse to explicit session level attributes (it just makes for easier
coding ;-)

2.4 Ideally we'd like to be able to grab sessions from sd(r) and use these
as the basis for SIP requests (drawing a colleague's attention to a
session, entering an MBONE booking in a personal calendar etc). If the sdp
syntax is used in SIP, this is fairly trivial to implement.

3. Response types: as the draft says new ones will probably be added as we
go - one such is DISCONNECT. Our SIP client sends this when a user
terminates a connection intentionally - it can be sent by either the
initiator _or_ the receiver of the request. This is prob. a category 2
message. Or is it a progress report (3)?

4. UDP as transport with retransmission and back-off: We've found this to
be effective in the local area (LAN). So far we haven't been able to test
it out in the wide area. More on that soon I hope.

For info: our SIP client has been developed to investigate UI rather than
technical issues and it's currently uncertain whether we (I) will have time
to make it fully SIP compliant. I'd like to but...

hope this starts some discussion

cheers
Ben.

******************************************************************************
This is <a href="http://pipkin.lut.ac.uk/~ben/sig.html">my signature</a>.