Subject: Re: Session Scheduling

From: Denis BIGORGNE <[email-masked]>
Date: Fri, 14 Jun 1996 22:46:30 +0200

Henning Schulzrinne wrote :

> The functionality you list is a pretty good description of what SCIP 
> and SIP can do.

I'm aware of that... But :

1) I don't see in the current drafts (SCIP-00 and SIP-00) any place
for time-slot negotiation (Am I wrong ?). A minimal request for date
negociation will be to have the possibility to specify several time-slot
in order to find one of them satisfying all the participants. In SDP,
multiple time fields are for multiple activitation of a session.

2) SIP run after the session creation. I understood that SCIP should
be run shortly before the beginning of a session. I want to be able
to schedule a session a long time in advance.

I don't want to push another protocol. If the scheduling and the
time negotiation functionality could be added to SCIP or SIP, it will
be perfectly OK. I was afraid of the added complexity, specially for
the ligth connectionless architecture of SIP.

Another aspect which could be highlighted is the redirection capability
or SCIP. It put the complexity of the effective contact with the user
(by phone, pager, etc...) on the initiator application, under protocol
constraint. It could be better to let this stuff to the local invitee agent,
acting as an interface between the initiator and the invitee. This way,
the initiator (appli) may have only one communication protocol, and
the invitee agent may be configured around the effective media available
to the invitee (this doesn't preclude an answer requesting a direct phone
call, itself out of the scope of the protocol and the agents).
    
> We are implementing a subset of that functionality 
> (including user location, email notification, automatic acceptance, and 
> interface to the phone network). 
Well, this complexity seems manageable... ;-)

Amicalement,

	Denis

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Jun 1996 19:11:37 +0200

I don't see why conference scheduling should be separated from a 
general distributed 'resource' scheduler, where the most common 
resource which people worry about scheduling is going to be people 
time, not network resources. Networks that constrain when a small group 
can meet won't be very popular... That said, one could easily imagine a 
'network stand-in' that would represent the scheduling constraints of 
the network. I'd leave the advance scheduling to the vCalendar (et al.) 
folks. Their stuff seems flexible enough to incorporate an SDP-like 
session description, if that's deemed appropriate. There's also an RSVP 
angle to this, naturally.

> call, itself out of the scope of the protocol and the agents).

This is not correct. A redirect can be handled by either the called 
party or the calling party. However, handling of redirects is pretty 
trivial (somewhere on the order of ten lines of code), so I don't 
anticipate that this will be left out even for simple end systems.

Since packet loss, reordering, duplicates, etc. are not possible when 
using TCP, one might argue that 'lightweight application' and 'UDP' are 
not necessarily the same....

Henning

---

From: Mark Handley <[email-masked]>
Date: Fri, 14 Jun 96 19:40:27 +0100

1) I don't see in the current drafts (SCIP-00 and SIP-00) any place
for time-slot negotiation (Am I wrong ?).

It's not in SIP because we hadn't though of it :-)

>to schedule a session a long time in advance.

Maybe the diagrams in the SIP spec are confusing here.  They are meant
to refer to typical sessions, but are not intended to be the only way
you can use SIP.  

*Normally* you use SIP before session start but after session
creation.  In lightweight sessions, session creation simply means
"allocating a multicast address".  In a tightly-coupled conference,
there is some form of admission control, and therefore whatever
performs that admission control needs to be initialised before the
first member can join the session.

>the ligth connectionless architecture of SIP.

SIP (and I assume SCIP) could be extended to perform time-negotiation.
What you require is a form of multi-phase negotiation.  In SIP, one
way this could be done is by allowing a what-if type request, which
even if successful does not trigger session state caching at the
receiver until an actual request is made to finalise things.  It looks
like we may need this for some other forms of negotiation anyway.

As for the light connectionless archtecture of SIP...  well that
probably buys you more than it loses you in this case because it
allows a "disconnect" between receiving (and acking) the request and
then the invited party making a return "connection" when a reply is
available (if it isn't available immediately).  However, this does
require some more thought as to the implications...

The negotiation aspects of SIP are not really very well finalised yet
though, and it's possible that a better approach would be to use SIP
to locate a user's calendar manager and then allow that to perform the
sort of multi-phase negotiation that is required.  This is in line
with current ideas on how to use SIP to initiate an T.120 or H.323
session where more detailed negotiation is performed after initial
SIP-initiated contact.

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 15 Jun 1996 09:50:25 +0200

> for time-slot negotiation (Am I wrong ?).
SCIP has a very rudimentary form of time-slot negotiation: the caller 
can propose a time slot, and the callee can respond "no, but...", 
suggesting an alternate time slot. This would be a kind of redirect (in 
time, instead of space), similar to the HTTP response code that asks 
the client to try again later. If the caller (conference initiator, if 
you prefer) agrees, he/she makes a second call with the new time and 
the call attempt should succeed. Note that in both cases the call 
attempt does not have to happen at the time of the conference.

Instead of a single slot, the caller could offer a list of possible 
time alternatives. Indeed, one would probably want the ability to 
describe a set of alternative conferences, since different time slots 
may also imply different capabilities (say, I may be on the road for 
one of the time slots and thus only have audio available). Writing 
protocol description (assuming a suitably general session description 
language) is the easier part, presenting this to the user in an 
understandable fashion seems far harder.

Henning