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

From: Dean Willis <[email-masked]>
Date: Mon, 10 Oct 2005 19:42:48 -0500

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

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 11 Oct 2005 10:38:31 +0300

Hi Dean:

As usually, there is a lot of logic in your reasoning...

I was also leaning towards 1 below, specially because this is a similar 
case to the MESSAGE URI-list service, 
draft-ietf-sipping-uri-list-message-03.txt

However, I see the point with other SIP methods... I guess that the 
conference server would always need some logic that determines what to 
do, depending on the method (yes, ugly). Common sense tells me that we 
want to do #1 for MESSAGE, but not for any other method.

And even #1 might have variations. For instance, one of the participants 
might have establish an MSRP session, but not support MESSAGE (I guess 
this is theoretical). The conference server could put the payload of the 
MESSAGE request in an MSRP SEND for that participant.

/Miguel

Dean Willis wrote:

> 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.
> 
> INVITE to a conference-factory, and completing an offer-answer  exchange 
> in the usual way. The conference factory indicates it  supports MESSAGE.
> 
> 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.
> 
> 3) Nothing -- that is, the conference UA eats the MESSAGE, because  it's 
> a dumb bot and rendering things to its user is meaningless.
> 
> 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.
> 
> directly rather than exploding the SUBSCRIBE request. And the same  for 
> NOTIFY, PUBLISH, INVITE, or any other request. So why should  MESSAGE be 
> special?
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Oct 2005 09:14:03 -0400

Dean,

I don't believe there is any good reason for Alice to *expect* any 
particular one of these things to happen. All of them seem like valid 
behaviors, and in the absence of some specification about what SHOULD 
happen, the implementation is free to do as it wishes.

*Perhaps* the work on the consent framework provides some justification 
for (5) in preference to (1) or (6).

I am slightly inclined to choose (6) as the way I would *like* it to 
work. But I think we need some additional specification before we can 
say that is the way it SHOULD be implemented. However I also find (2) to 
be a potentially useful behavior. These could be combined, so that the 
focus strips out any messages it feels should be handled by it, and then 
explodes others out to the participants.

I don't buy the argument that (1) should hold because MESSAGE is like 
any other media. It most decidedly is NOT like other media. You don't 
get the opportunity to negotiate the use of MESSAGE the same way you do 
other media. If you want something that is, there is MSRP.

	Paul

> in the usual way. The conference factory indicates it  supports MESSAGE.

I'll pick a nit here. The INVITE may go to a conference factory, but it 
completes with a dialog to a conference focus, and it is the focus that 
indicates it supports MESSAGE.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 11 Oct 2005 09:43:38 -0500

> be than I thought I would be.
[...]
> So what do you think happens here, and why?

Dean:

Knowing you, I am apt to think that there is something more
going on in your mind ;-)  Clearly, I think you are well aware of
the pros and cons of each of the options you listed.  What I am
more interested in is, why the question?  Are you trying to
highlight the wide variability of implementations?  Or the various
unintended ways in which a specific request interacts with a
specific entity processing it?  Does that mean more work is needed
in the realm of defining applicability of existing requests to
new entities like conference factories, focus?  ...?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Ph.D.  vkg@{lucent.com,research.bell-labs.com,acm.org}
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
_______________________________________________
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

---

From: Dean Willis <[email-masked]>
Date: Tue, 11 Oct 2005 14:33:01 -0500

> new entities like conference factories, focus?  ...?

Ah, grasshopper, I wish I knew.

The short answer is that the question came up in OMA, and I realized  
I didn't have a completely satisfactory (to me) answer and that we  
really need to think it over "on a larger scale".

I suspect that you're right about needing to define the applicability  
of existing (and future) requests to automata. It probably means that  
there's a family of unexplored shortcomings to our current  
conferencing model.

SIP has gotten very, very muddled over the last few years. Partly  
that's because of some deep-seated structural flaws (and the  
associated band-aids), partly due to usage ambiguities, and partly  
due to the diverse and conflicted world-views of the contributors. I  
suspect that this leaves us with some questions that are essentially  
unanswerable without rethinking at least part of the muddle.

The good news is, we've learned a lot. The bad news is that it's  
awfully hard to apply.

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 19 Oct 2005 22:39:38 -0400

> participants? I think we assume that the the conference UA responds  

That seems certain -- The conference focus is a UA, and by the RFCs, it
must respond to OPTIONS describing its capabilities.

> directly rather than exploding the SUBSCRIBE request.

In principle, it depends on the event type of the SUBSCRIBE, since the
semantics of SUBSCRIBE is defined only on an event-type-per-event-type
basis.  But all of the event types I am aware of are defined in terms of
reporting the status of the UA which receives it.  (And none of those
would require the focus to establish subscriptions with the other
participants to determine what its reportable status is.)

Hmmm, one can say that more strongly -- a SUBSCRIBE could not be forked
to the other participants, because the forked copies could not be within
the established dialogs between the focus and the participants -- being
distinct dialogs, they have different Call-IDs.  And no current event
type has a defined way for a B2BUA to collate NOTIFYs from multiple
subscriptions to produce a collective NOTIFY.

> And the same  

INVITE, NOTIFY, and PUBLISH are strictly defined as well, and none of
those would be forked.

The distinction with MESSAGE is that its semantics are not defined,
really.  So there is no way to predict a priori how a given conference
bridge will act on a MESSAGE.  (I think INFO is in a similar condition.)

Perhaps we could say the crux is:

> The conference factory indicates it supports MESSAGE.

Unless the factory has some defined behavior in regard to MESSAGE, it
shouldn't indicate support of MESSAGE.  Presumably UAs that send
MESSAGEs to it (or indicate they are willing to receive MESSAGEs from
it) have an out-of-band understanding with the conference bridge in
question.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2005 09:27:20 -0400

> subscriptions to produce a collective NOTIFY.

No? What about event lists, which apply to all kinds of events?

A conference focus could be viewed as just a special kind of event list.

> INVITE, NOTIFY, and PUBLISH are strictly defined as well, and none of

INVITE presents its own problems. But NOTIFY and PUBLISH are similar to 
SUBSCRIBE, in that the focus could be viewed as an event list.

> it) have an out-of-band understanding with the conference bridge in

It would be helpful if there was some defined behavior of foci for all 
of these things.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 20 Oct 2005 09:52:32 -0400

> A conference focus could be viewed as just a special kind of event list.

Ah, I was unaware of event lists.  Though technically, a resource list
server is the notifier for the event list subscription and the
subscriber for the back-end subscriptions that it is aggregating.  But
the event list mechanism does provide a blanket interpretation for
SUBSCRIBEs to the conference focus URI.

Though this can be applied to all event types, can it?  Subscriptions to
conference events always regard the focus, not the conferees.

> SUBSCRIBE, in that the focus could be viewed as an event list.

NOTIFY is always within-dialog, so its meaning piggybacks on SUBSCRIBE.
But PUBLISH to an event list could be interpreted to mean forking.
(Though I've not heard of that being defined.)

> It would be helpful if there was some defined behavior of foci for all 

I'm not sure that this can be done successfully.  Foci are (can be)
(will be?) considerably more complicated in their behavior than proxies;
I'm not sure we can write a one-size-fits-all set of rules that is
adequately future-proof.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 29 Oct 2005 22:37:26 +0300

Hi Dean,

the conference server would do 6). The consent framework avoids that I 
add you to a distribution list. In this case, you yourself have joined 
the distribution list by joining the conference. There is no consent 
problem here.

The fact that different methods are proceessed in different way is not a 
problem either. The fact that the processing of the MESSAGE, as defined 
by the service being provided (i.e., a conference), involves generating 
a request towards the other participants does not mean that you have to 
process other methods in the same way. The processing of an OPTIONS 
request only involves the generation of a response. The processing of a 
SUBSCRIBE request involves generating NOTIFY requests... different 
methods, different processing rules.

This is actually the reason why we defined different URI-list services 
that deal with different methods, as opposed to a generic exploder that 
deals with every SIP method. We did not want to have a dumb exploder 
that explodes any method it receives. We want application servers that 
understand what they are doing when they explode something.

Cheers,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Dean Willis <[email-masked]>
Date: Sat, 29 Oct 2005 15:45:27 -0500

On Oct 29, 2005, at 2:37 PM, Gonzalo Camarillo wrote:

> Hi Dean,
>
> the conference server would do 6). The consent framework avoids  
> that I add you to a distribution list. In this case, you yourself  
> have joined the distribution list by joining the conference. There  
> is no consent problem here.
>
> The fact that different methods are proceessed in different way is  
> not a problem either. The fact that the processing of the MESSAGE,  
> as defined by the service being provided (i.e., a conference),  
> involves generating a request towards the other participants does  
> not mean that you have to process other methods in the same way.  
> The processing of an OPTIONS request only involves the generation  
> of a response. The processing of a SUBSCRIBE request involves  
> generating NOTIFY requests... different methods, different  
> processing rules.
>
> This is actually the reason why we defined different URI-list  
> services that deal with different methods, as opposed to a generic  
> exploder that deals with every SIP method. We did not want to have  
> a dumb exploder that explodes any method it receives. We want  
> application servers that understand what they are doing when they  
> explode something.
>

I'm willing to believe that a reasonable conference server might  
behave this way.

Do we, in the conferencing framework or elsewhere, explicitly  
describe this behavior, as well as how conference servers act with  
other requests (I couldn't find it in framework, but it might be there)?

Do we need to add guidance for the developers of new request types to  
say how those requests interact with conferences?

--
Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 29 Oct 2005 23:56:11 +0300

Hi Dean,

yes, when we specify a service such as conferencing, we should provide 
guidelines about how to treat different methods every time the 
processing of those methods differs from what is typically expected from 
a UAS on reception of each method.

Handling of REFER requests is described in the specs. SUBSCRIBE requests 
for the conference package are described in the specs. OPTIONS does not 
have any special meaning in conferencing, so, there is no need to 
specify anything new. MESSAGE, as you point out, is not covered by the 
specs, though...

As a general rule, if somebody defines a new method and expects some 
type of interaction with an already specified service, he or she should 
point it out.

Cheers,

Gonzalo

Dean Willis wrote:
>> the conference server would do 6). The consent framework avoids  that 
>> I add you to a distribution list. In this case, you yourself  have 
>> joined the distribution list by joining the conference. There  is no 
>> consent problem here.
>>
>> not a problem either. The fact that the processing of the MESSAGE,  as 
>> defined by the service being provided (i.e., a conference),  involves 
>> generating a request towards the other participants does  not mean 
>> that you have to process other methods in the same way.  The 
>> processing of an OPTIONS request only involves the generation  of a 
>> response. The processing of a SUBSCRIBE request involves  generating 
>> NOTIFY requests... different methods, different  processing rules.
>>
>> exploder that deals with every SIP method. We did not want to have  a 
>> dumb exploder that explodes any method it receives. We want  
> I'm willing to believe that a reasonable conference server might  behave 
> this way.
> 
> Do we, in the conferencing framework or elsewhere, explicitly  describe 
> this behavior, as well as how conference servers act with  other 
> requests (I couldn't find it in framework, but it might be there)?
>