Subject: [Simple] Requirements to SIMPLE components continuation

From: "Petri K. Koskelainen" <[email-masked]>
Date: Sun, 24 Mar 2002 19:51:04 -0500 (EST)

Hi,

Since each member in a conference has a different call-id for
SIP signaling (with the server), how can you send one-shot MESSAGE 
directly to recipient and use call-id information to indicate
that this refers to existing conference?

The sender does not know about call-id's between server 
and recipient, and there isn't any conference wide call-id.

Petri

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Stephen Gryphon" <[email-masked]>
Date: Mon, 25 Mar 2002 15:51:20 +1100

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:[email-masked]]

I don't think one-shot MESSAGE's are a good idea, but, depend on the implementation assumptions, it may work anyway. 

Using the conference server for passing the private MESSAGE (in-session) makes a lot more sense.

Assuming the setup is per a MESSAGE session, with the signalling channels only setting up the conference session. Clients will then have a separate media channel for content MESSAGE's, which could share a common call-id. 

One-shot MESSAGE may work if the sender uses this common session Call-ID, and the recipient just threads all with the same Call-ID (irrespective of other headers). [I still don't like it though.]

==

Not sure what others think, the  assumptions of a common Call-ID for the conference session makes good sense to me. In particular, when the conference server receives a MESSAGE the only thing it needs to change when broadcasting is the Request-URI.

Whilst the message delivered to conference participants may then seem a little strange (e.g. it is neither To them, nor From anyone they are in direct contact with), this is not much different from when you are receiving from a proxy.

It also makes the processing by the conference server very quick (rewriting To, From, and Call-ID for each outgoing connection would be extra work). 

Keeping the From address also allows the UI to display the author of each message (this was a problem with draft-khartabil-sip-conferencing-00, there was no way for the recipient to identify, and hence display, the author of a message).

In fact, if you embed the conference identifier in the conference Request-URI, then you could actually stream incoming messages straight to outbound pipes, if you wanted a particularly fast conference server.

I have some samples of the message flow, if anyone is interested.

==

Can anyone see any problems?

- Sly

---

From: [email-masked]
Date: Mon, 25 Mar 2002 23:17:30 +0200

Paul Kyzivat wrote:
>
> I would prefer that the side conversations be entirely 
> independent the shared conferencing components - via 
> page-mode MESSAGE exchanges, or via a separate MESSAGE session.
> 
> (This doesn't prohibit the GUI tying these together, based on 
> In-Reply-To headers or the like.)

I guess the requirement itself is still fine. It should be possible for the recipient to show the "private" message in the right context, like in the same window where the chat conference is ongoing (as in Netmeeting). If a separate page-mode MESSAGE with In-Reply-To etc. is able to do this, it is probably OK. 

> However, it might make sense to access-control the various 
> presence attributes, so that only certain people are 
> permitted to see detailed information while a larger set of
> people may see more general information. This would fit in 
> well with filtering - requests for too much detail might fail 
> for some users, where they would succeed when using
> a suitable filter. (Or else, the required filter could be 
> automatically applied to avoid refusing the request.)

Yes, I think this should be possible. There should be at least two levels, e.g. "public" (everyone) and "private" (my buddies or co-workers etc.). Even this might be too complicated for most users to set, but for some it could be useful. 

I think the filtering and other access rules should be such, that also the access to geographical location info could be controlled by them (as part of presence or as a separate event package?), if at all possible. GEOPRIV probably has some quite strict privacy requirements related to that.

Markus 

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 25 March, 2002 21:22
> To: Isomaki Markus (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Requirements to SIMPLE components continuation
> 
> 
> 
> 
> [email-masked] wrote:
> > 
> > Hi,
> > 
> > It seems that work based on the proposals in the SIMPLE 
> components draft is getting started within SIMPLE and SIPPING.
> > 
> > In addition to those mentioned in the draft and 
> presentation, I would like to propose the following requirements:
> > 
> > - Private messages in a multiparty centralized conference 
> with messaging sessions. This means that if a number of 
> participants are in a conference/chat via a centralized 
> server it should be possible to send a private (i.e. only 
> shown to the selected recipient, not the whole conference) 
> message between two participants. It must be possible to 
> correlate it somehow on the ongoing conference, so that it 
> can be shown correctly on recipient's chat window, meaning 
> that a completely separate one-shot message is not the right solution.
> 
> I question this. Why should private side messages involve the 
> conference as a whole at all? This seems to violate the 
> notion of the conference. And, why would I trust that
> a message delivered through a conference server will only 
> been seen by my intended recipient? My willingness to trust 
> this will probably vary depending upon how the
> conference is implemented. (For instance if the moderator of 
> the conference is not my intended recipient.)
> 
> I would prefer that the side conversations be entirely 
> independent the shared conferencing components - via 
> page-mode MESSAGE exchanges, or via a separate MESSAGE session.
> 
> (This doesn't prohibit the GUI tying these together, based on 
> In-Reply-To headers or the like.)
> 
> > 
> > - Showing different presence information to different 
> Watchers. This means that e.g. for some Watchers the status 
> of IMs is just "closed", while for others something more 
> accurate could be shown. So, basically the presence doc. is 
> formed based on who is asking for it, and there must be a way 
> for the presentity to control this.
> 
> This may be probematic because of scaling problems. If a 
> separate view has to be computed for every watcher then it 
> may not be possible to use use presence servers to
> distribute presence state to the masses.
> 
> However, it might make sense to access-control the various 
> presence attributes, so that only certain people are 
> permitted to see detailed information while a larger set of
> people may see more general information. This would fit in 
> well with filtering - requests for too much detail might fail 
> for some users, where they would succeed when using
> a suitable filter. (Or else, the required filter could be 
> automatically applied to avoid refusing the request.)
> 
> > 
> > - Presence subscription filtering. This means that a 
> Watcher should be able to presence to the changes in certain 
> _part_ of the presence info. If other parts change, NOTIFYs 
> are not generated.
>