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

[Miguel Garcia <[e-mail]>]

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:

> 
> 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


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