Subject: RE: [Simple] Three dimensions of service

From: [email-masked]
Date: Fri, 18 Feb 2005 13:30:32 +0200

Hi,

Commenting only to a couple of points in the discussion. (I'm not sure whose comments all originally were.)

Jonathan Rosenberg wrote:
> 
> inline.
> 
> Aki Niemi wrote:
> 
> > Inline.
> > 
> > ext Jonathan Rosenberg wrote:
> > 
> >>> Why precisely will this fail?
> >>
> >>
> >>
> >> Others know OMA PTT better than I, but I'll take a stab.
> >>
> >> The OMA client assumes that both sides support the floor control 
> >> protocol they are using. It also assumes that PTT calls 
> have passed 
> >> through a network with specific topologies that invokes the PTT 
> >> arbiter in the right places. There is nothing in the 
> protocol messages 
> >> that conveys the latter assumption. I am not sure if OMA 
> is using SDP 
> >> to signal the floor control.
> > 
> > 
> > I believe they do signal it in SDP. That is the sanest thing to do 
> > anyway, because when floor control is explicitly signaled, 
> then you can 
> > also upgrade or change that protocol to something else in 
> the future and 
> > clients can handle legacy gracefully.
> 
> Right. The issue that makes it non-SIP in this regard is that 
> there is 
> no fallback if that SDP stream is not present in the INVITE request.
> 

To my understanding these type of issues, e.g. what to do when some media streams are present or not present, are part of the application logic. Usually that type of logic is left to the implementation. In case of OMA PoC some parts of the application logic have been "standardized" too. That still does not make it non-SIP. Also, I don't think there is anything that would really prevent a PoC conference server to accept an INVITE without the floor control. However, that might lead to a strange user experience especially in a one-to-one call (which is still done as a conference), depending on how the other party's application has been implemented.

My conclusion on this is that whether we want it or not, there will be this type of weird application logics/limitations on topic of SIP in any case, and we just have to have a way in presence to cope with those. Presence should be aiding users/applications, not dictating what they are allowed to do.

If I happen to have a PoC application that works in a way that it does not *want* to fall back in case there is no floor control, I would need to express that I have an application which can be contacted succesfully only if the caller has certain capabilities (that can work together). Since prescaps does not allow that, it makes it easier to just say "org.oma.poc-1.0" than "half-duplex" & "voice" & "floor-control" & "PoC-feature-tag". Contact would be sip: or sips: in any case.

If I have an application that can do VoIP in addition to PoC I would say "org.oma.poc-1.0" & "voice", but of course that could be in the same tuple only if those two have the same status.
> > 
> >>> I would rather extend prescaps if it can't do the right 
> thing now, 
> >>> i.e., describe composable protocol behavior elements 
> rather than just 
> >>> lump everything into a label.
> >>

This is a desirable property, but it really assumes that there would be a fallback even in cases where certain set of the componets is not supported. Surely SIP itself works like that, but all the applications do NOT. In Presence we are somewhat describing the application in addition to the protocol capabilities too.

I don't know where we are with prescaps, but I think the only way to prevent labels would the capability of expressing "you have to support all of these components to interact with my application".

>
> 
> I fear there is some perception here that the data model is 
> saying that 
> presence states aren't extensible. I don't know what in the document 
> would convey that impression though.
>

Right. I think that in the model discussion we merely need to understand what the extension points are and how such extensions interact with the composition.
 
> > 
> > The only thing where the model is affected is that if you have two 
> > tuples that have the same extension that is unknown to the 
> composer, but 
> > known to the watcher, and one has value foo and one has 
> value baz, the 
> > composer *cannot* merge the states (tuples) because it doesn't know 
> > whether to choose foo, baz, or put both in.
> 
> This is fodder for the presence processing draft that I just 
> submitted 
> (which is basically the tail end of the former data model draft). It 
> needs to address merging rules for unknown attributes. That is a 
> reasonable thing. However, there are problems. If the 
> compositor doesnt 
> know the extension, the only outputs it can produce which 
> have a chance 
> of being compliant to that extension are to pick one. I don't 
> think it 
> can put both in, since the schema may not allow it.
> 

Again the problem seems to be that it is impossible to determine what the intention is: replace or append. That is why I thought it to be valuable to have some sort of identifier in the tuple itself for this (and since we determined that the contact URI can't be used for this, it would need to be something else). 

Markus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Feb 2005 08:49:20 -0500

Hi Markus,

I think it is looking productive to look in detail at POC. I think as we 
do so we will be able to find a way to describe this and keep the 
presence system rational. Comments inline.

	Paul

[email-masked] wrote:

[trimming]

(the below refers to floor control)
> To my understanding these type of issues, e.g. what to do when
> some media streams are present or not present, are part of the
> application logic. Usually that type of logic is left to the
> implementation. In case of OMA PoC some parts of the application
> logic have been "standardized" too. That still does not make it
> non-SIP.

I think this may be part of a larger problem. That is: what should 
happen when all the media in an offer are not supported by the answerer?

The specification in the offer/answer rfc is that those which are not 
accepted should be refused by setting the port number to zero. In 
practice, it is common for a UAS to refuse the call if the result would 
be a call with no media. That makes reasonable sense in the case of a UA 
that only supports one medium (audio), especially when in the vast 
majority of cases audio is the only medium that will ever be seen.

We need to start thinking of how this should work in a world where there 
are serveral media in common use, and devices that are flexible in their 
use of media - with the possibility to enable and disable the use of 
particular media.

It seems reasonable to me that UAs should be more tolerant in how they 
handle media mismatches - perhaps at least alerting and letting the user 
decide. In some cases it may be reasonable to accept the call even 
without the exact media configuration that the UA prefers - operating in 
degraded mode, and possibly hoping that reconfiguration of one or the 
other of the parties in the call will make things better.

> Also, I don't think there is anything that would really prevent a
> PoC conference server to accept an INVITE without the floor control.
> However, that might lead to a strange user experience especially in
> a one-to-one call (which is still done as a conference), depending
> on how the other party's application has been implemented.

That's exactly the kind of thing I was talking about above. It might not 
be great, but it might be better than nothing.

> My conclusion on this is that whether we want it or not, there will be this type of weird application logics/limitations on topic of SIP in any case, and we just have to have a way in presence to c…

I think we need to strike a balance here. We don't want to be 
unreasonable. But neither do we want to encourage balkanization of services.

It might be easier for a particular endpoint to simply advertise its 
brand and model, and expect to talk only to others the same. Then it 
could be confident there are no incompatibilities. But we don't want to 
encourage that either.

> If I happen to have a PoC application that works in a way that it
> does not *want* to fall back in case there is no floor control,
> I would need to express that I have an application which can be
> contacted succesfully only if the caller has certain capabilities
> (that can work together).

I agree it would be good to be able to express that. I think that can be 
a subject of future work.

> Since prescaps does not allow that, it makes it easier to just say
> "org.oma.poc-1.0" than "half-duplex" & "voice" & "floor-control" &
> "PoC-feature-tag". Contact would be sip: or sips: in any case.

Well, I agree it is "better" than the alternative you list, in the sense 
that it doesn't make claims that can be misinterpretted. But it is not 
"good".

I especially think that treating this as a unique "capability", that 
could be combined with others, is preferable to introducing a "service 
type" that each tuple has exactly one of.

> If I have an application that can do VoIP in addition to PoC I would say "org.oma.poc-1.0" & "voice", but of course that could be in the same tuple only if those two have the same status.

Agree.

> I don't know where we are with prescaps, but I think the only way to prevent labels would the capability of expressing "you have to support all of these components to interact with my application".

I think this is something we should pursue.

	Paul