Subject: Re:

From: Mark Handley <[email-masked]>
Date: Wed, 11 Oct 95 14:16:24 +0100

>A draft paper on a call control/invitation protocol is available at
>ftp://gaia.cs.umass.edu/pub/Schu9510:Personal.ps.gz
>
>We have done an initial implementation, but it's not quite ready for 
>release yet.
>
>A side note: We found the SDP format to be too cumbersome and too 
>different from 'standard' request/reply conventions and thus 
>reluctantly chose a more MIME/HTTP-based format for media description. 
>It's also slightly more compact.
>
>I'm also trying to show to a more Telecom-oriented crowd that Internet 
>technology plus some relatively minor enhancements can provide services 
>which are at least equal to those envisioned for so-called 'intelligent 
>networks'. (Just leaf through some of the more recent IEEE 
>Communications Magazines for a sampling.)
>
>Comments are appreciated.

This looks like a good sensible well thought-out protocol, and has all
the advantages of being similar to something we're familiar with.  I
like the use of email addresses as your naming scheme.

I'd just like to add a few comments/observations:

I'm not completely sure of the semantics of the "Required" and
"Accept" fields.  As I understand it, in a request, multiple
"required" fields mean all are compulsory.  Multiple sections within a
field mean one of these is compulsory, and that sub-fields are in
order of preference.  Now, the callee returns an Accept field for each
Required field inthe request, giving the possible acceptable
alternatives.  There is no further round of negotiation, unless you
make a new connection with a Change request.

This is OK if the alternatives are provided by a single tool - on
acceptance of the call, I can start up a media tool that will handle
all the alternatives.  However, if the different encoding schemes are
not handled by the same tool, or are specified on different ports (as
in your example for video), then I have to rely on the order of the
"required" fields to decide which tool to start.  If this is a
multi-way conference, then I cannot start any tool (without confusing
the user by possibly then killing it and starting an alternative)
until I get a new connection containing a Change request, as I cannot
know if the other conferees supported the first choice I accepted.

It seems you really need to have a two-phase negotiation in most
multi-way situations when want to specify alternative coding
schemes.  If this is going to be the norm for small conferences,
you probably should support it in your protocol directly by leaving
the connection open when you know you'll need a second phase and using
the open connection to transfer your Change request.

On a slightly different matter - that of Change requests through
Proxys: You state that "If a server operates in Proxy Mode, it should
cache call Ids .... However should it 'forget' a call ... it can
always treat a change request like a new call and locate the user"
Now, I'm not convinced this is always the case.  You have a "Reach"
field which can be set to "first" which basically states that the call
is to be taken by the first callee from a group that answers.  Now
there's no guarantee that the first callee that answers the original
call will be the first callee that answers the change, so it appears
that under these circumstances, you may have no way to update the
conference settings.

A third point - you have two modes your server can operate in -
"redirect" mode and "proxy" mode, and you state that you can freely
mix the two modes within a call.  It's not clear from the paper what
the semantics of mixing the two are.  For example, if a call routes
through a proxy, then gets a redirect, does the proxy get redirected
or the original client?

If your call has a Reach of "all", you probably want the proxy to
intercept the redirect, or you may lose the possibility to contact the
rest of the group  (of course you then have to have the proxy server
doing loop detection for the redirects).  

I'm not convinced by your assertion that MUCS is more compact than
SDP, but I'll let that pass for now :-)

When will the code be available?

Mark