Subject: negotiation & SIP etc

From: [email-masked] (Ben Anderson)
Date: Fri, 28 Jun 1996 12:55:57 +0000

Given the considerable discussion (and confusion) about negotiation at the
IETF mmusic sessions I thought maybe I could start some more...:)

Negotiation - I'd suggest negotiation is the process of attempting to reach
an agreement on something (duh). So, in our case it is the process of
trying to reach agreement on session parameters - we can think of it as
trying to produce an SDP description that satisfies all concerned.

Now, note that this negotiation can occur in a number of places:

- Before the session set-up process. This may sound illogical but if a user
is aware of the capabilities of/constraints on the person/s they are about
to send an invitation to, they may well alter the session description
appropriately themselves. It may be that this can alleviate some of
complexity in negotiation. How would we do this?

- During the session set-up process which is what SCIP/SIP set out to do
(yes?). Given that an invitation protocol may be used to set up a session
of arbitrary size, as the size of that group increases we might expect that
the complexity & overhead of the negotiation will increase as well. A
negotiation process needs to be able to cope with this. If there is a
sufficiently rich set of ways that participants can vary (and with SDP I
suspect there might be) we may never in fact reach an agreement. What then?

- During the session itself. Someone commented at the IETF (1st session I
think) that once the session had been set up then that was that for
negotiation. This is a dangerous assumption to make because it implies that
the inviter/invitees know in advance exactly what they will do during the
lifetime of the session. This is not the case. We can imagine, for example,
a medic setting up a video session with a colleague in order to view a scan
animation (or whatever). However, part way through they realise that they
need to alter or fine-tune the parameters in order to see extra details
(change b/w, format etc). This is also negotiation. We might try to call
this session control (?) or signalling (?). We might also say that it is,
in fact, creating a new session with the new parameters in which case we
could cycle through the invitation process again. But perhaps we don't need
to - in this instance qute a lot of the negotiation may be done by the
people in the session (eg via audio) rather than by a protocol - they can
alter the parameters themselves.

Following from this last point, it's not clear to me how much of
'negotiation' we can safely leave to the system/protocols and how much the
users might need to be part of the loop. People are pretty good at
negotiation after all...

So, I don't see negotiation only taking place via SIP/SCIP/whatever - it
can occur in various places and perhaps we need to think about how we can
support this range. Different mechanisms may well be required for each.

hope some of that made sense.

Ben.

******************************************************************************
                http://pipkin.lut.ac.uk/~ben/sig.html

---

From: Jon Knight <[email-masked]>
Date: Fri, 28 Jun 1996 16:04:28 +0100 (BST)

> suspect there might be) we may never in fact reach an agreement. What then?

I think that there's likely to be some circumstances where the system has
to have the option of throwing its virtual arms up in the air and saying
to the users "Tough; you've got no hardware/software in common and so you
can't talk to each other".

> People are pretty good at negotiation after all...

Obviously Ben was watching some different IETF sessions on the MBONE to 
me... :-) :-)

Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Jul 1996 17:24:34 +0200

> complexity in negotiation. How would we do this?

This will depend on how anonymous the session is. If I create a session 
for a large audience, negotiation will happen in three ways:
(1) the creator will estimate what it takes to reach that target 
audience
(2) he/she will be told by email, etc. if the guess was off, go back to 
(1)
(3) the participants acquire whatever software/hardware is required.

Not much protocols can do here. For these types of large events, the 
only realistic option is to come to some agreement on a base set of 
functionality. These may well be community-specific. In some cases, 
this will mean that you have to send the same information twice - the 
equivalent of having 'text-only' and 'graphics' WWW pages.

Also, we better not assume that negotiations are symmetric, in that 
everybody is equal. If one of the other participants happens to be the 
CEO/university president/etc. and you're not, whose preferences or 
equipment capabilities will win.

> suspect there might be) we may never in fact reach an agreement. What then?

If you always want connectivity, you have to specify: a set of media 
types and a common set of encodings for these. Nothing else you can do.

A typical on-line small-group negotiation would simply gather 
capabilities or preferences, say, in order of importance of attendees 
and then, in a second round, distribute the *set* of allowable 
encodings to everyone. (Note that, as far as I can tell, the 11/95 SDP 
spec does not allow for suggesting a set of allowable media types for a 
medium.) Another, less desirable outcome might be to force parallel 
sessions (the equivalent of the MIME alternate type). Another the 
(automatic?) installation of translators or mixers.

> 
> - During the session itself. [...]

Note that there's no reason SCIP (or, I presume, SIP) can't be used to 
modify an existing conference. This is needed to add media or to modify 
the set of allowable media encodings in any event.

This assumes that there's some (logical) central entity (such as the 
convenor or whatever the T.120 term is) that keeps track of things and 
decides policy (who's important and who's to be ignored if necessary, 
say). The Schooler/Weinrib agreement protocol description has much more 
to say on this and other issues.

It is up to the user agent to do one of several things:

- automatically respond to an invitation by giving a stock answer;
- request help from the user (pop up a window "You've been invited to 
talk to Bill Clinton <[email-masked]>. Your current profile 
indicates that you do not accept video/some-evil-format. Would you like 
to override this choice?"

The protocol is not affected by this user agent behavior, it just needs 
to be able to express choices and answers.

There is an important decision for this type of negotiation: Should the 
inviting party offer all possibilities (in some order), including ones 
we really don't like (but would use rather than not communicate at all) 
and let the invited party choose, or should we have a 
proposal-counterproposal game, where neither side reveals its 
preferences initially? Frankly, I see only complication as the pay-off 
for hiding preferences in this case - we are not building a generic 
protocol for buying companies, negotatiating used-car prices or Middle 
Eastern peace deals, where not revealing my set of acceptable outcomes 
is obviously needed.

SCIP chooses to have the caller offer the set of choices and let the 
callee respond with another set. The invited party can assume that if 
it chooses a subset, it will be able to participate until told to do 
otherwise (e.g., after the convenor has solicited opinions from 
everybody else). There's only a one-step exchange here.

> support this range. Different mechanisms may well be required for each.

The question is whether SIP or SCIP "go away" once the conference is 
under way. For the reasons above, I don't see this as necessary or 
useful. Conferences don't just start, stay unchanged and then go away 
all media at once. Going from 0 to 1 media is not very different than 
going from 2 to 3. After all, a conference (in the multicast context) 
is just a shared agreement to refer to a bunch of multicast or unicast 
streams by a common name. It doesn't exist in any tangible way by 
itself, unless you assume that conferences are only those with 
announcements appearing every so often in the session announcement 
multicast group. (Even here, things get tricky. Imagine inviting 
somebody to such a directory-announced conference and then trying to 
add or change its parameters - currently we just support 'reference by 
value', and not 'reference by pointer'...).

Henning

P.S. For a slightly elaborate form of negotation, check out Dr. Seuss 
"Green Eggs and Ham". 

http://www.coloacad.pvt.k12.co.us/~jham/green.html