Subject: RE: [Sipping] Use of MESSAGE within a conference.

From: "Even, Roni" <[email-masked]>
Date: Tue, 11 Oct 2005 09:42:53 +0200

Dean,
My view is that on MESSAGE the conference bridge that signal that it
supports MESSAGE, should act as it will on any other media. That means
that it will send the MESSAGE to all the participants that can receive
it (This is your number 6). Conference participants may only receive
part of the conference media like an audio only participant in a video
conference so only the participants that indicated that they support
MESSAGE will get it.
The difference from the other methods you mentioned is that MESSAGE is a
media like video or audio. If the user wants to send a MESSAGE to one
participant or to the operator it may do it directly (without dialog)
based on the user list he got from the conference event package.

For OPTION the conference bridge respond with its own options.

Subscribe I think is well defined. The conference bridge will support
the conference event package and may support other packages like dialog
(this will be on the dialog between the UA and the conference bridge.
The user will know the rest of the participants from the conference
event package.
If the conference bridge decides to subscribe to a package on the user
UA it is meant for the conference bridge. The Notifies that the bridge
will get are processed by the bridge and than it is up to the bridge to
decide what to do with it. An example is a cascaded conference where the
one conference bridge subscribed to the other conference event package
and when it receives a notify it may send notification to all its
subscribers.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, October 11, 2005 2:43 AM
To: Sipping
Subject: [Sipping] Use of MESSAGE within a conference.

Tom Hiller asked me this question, and when I thought about it, I
realized I was a lot less certain of what I believed the answer should
be than I thought I would be.

So I'll ask you folks.

Let's say Alice connects to a voice conference call by sending an INVITE
to a conference-factory, and completing an offer-answer exchange in the
usual way. The conference factory indicates it supports MESSAGE.

What should Alice expect will happen if she sends a MESSAGE to the
conference URI resulting from this transaction?

1) The conference UA ACKS the MESSAGE and sends duplicates of it to all
other participants in the conference who have indicated they support
MESSAGE.

2) The conference UA absorbs the MESSAGE, and if the contents thereof
are meaningful to the conference UA, acts on it.

3) Nothing -- that is, the conference UA eats the MESSAGE, because it's
a dumb bot and rendering things to its user is meaningless.

4) The conference UA displays the MESSAGE contents to its operator.

5) The conference UA rejects the MESSAGE, because it doesn't have
consent from the other conference participants to act as an exploder.

6) The conference UA acts as #1 above, because by joining the conference
and indicating support for MESSAGE, all participants implicitly granted
exploder rights to the conference UA.

My initial answer was #1.

Then I thought: What happens if aI send an OPTIONS to a conference UA?
Does it respond, or does it explode that request to the participants? I
think we assume that the the conference UA responds directly.

What about SUBSCRIBE? Again, I think the conference UA responds directly
rather than exploding the SUBSCRIBE request. And the same for NOTIFY,
PUBLISH, INVITE, or any other request. So why should MESSAGE be special?

So what do you think happens here, and why?

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP