Subject: RE: [Simple] Presence Data Model: Identifying services

From: Goeman Stefan <[email-masked]>
Date: Thu, 23 Sep 2004 13:41:37 +0200

Hello,

Comments inline

P.S.: In general, I find the Presence Data model draft a good document. This
is how things should have started in the first place.

Greetings,
Stefan.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: donderdag 23 september 2004 10:10
> To: [email-masked]
> Subject: [Simple] Presence Data Model: Identifying services
> 
> 
> Hi all,
> 
> I have a comment on Presence Data Model draft about the 
> identification/characterization of services. (I know this has 
> been discussed for a while already, but I still think the 
> current way is somewhat unadequate.)
> 
> The current Data Model draft says:
> 
>    In this model, services are not explicitly enumerated.  That is,
>    there is no "service" attribute with values of "ptt" or 
> "telephony".
>    Rather, the service is identified in one of two ways.  In 
> many cases,
>    the URI scheme is a clear indicator of service.  An "sms" 
> URI clearly
>    indicates SMS, and a "tel" URI clearly indicates 
> telephony.  For some
>    URIs, there may be many services available, for example, SIP.  For
>    those services, each service has a set of characteristics, each of
>    which has a well-defined meaning, such that a system can
>    unequivocally determine whether or not the service has that
>    characteristic.  This is discussed in more detail in [5]. 
> 
> I agree that the contact URI scheme is the most important 
> piece of information to distinguish what is the "service". 
> (There are some gaps here too, since e.g. the URI schemes for 
> SMS or MMS do not even exist, and there may be other non-IETF 
> protocols that face the same problem.) However, I'm not 
> convinced that listing the signaling/media characteristics of 
> the end-point or service really gives enough information to 
> the watcher to really determine if it can communicate with 
> the advertised service/application. 
> 
> The refenced draft [5] has a following example:
> 
> 5.6 Walkie-talkie
> 
>    The walkie-talkie service allows real-time voice communication
>    between participants.  Only one participant can speak at a 
> time; that
>    is, communication is half-duplex.  Typically, participants press a
>    button to indicate that they are ready to speak, although other
>    mechanism (e.g.  voice activation) are occasionally used.
> 
>    Support for the Walkie-Talkie service can be deduced by 
> observing the
>    presence of a contact URI with a scheme of "sip:", associated with
>    the following minimal set of capabilities: <audio>true</audio>
>    <duplex>half</duplex> <methods>INVITE,ACK,BYE,CANCEL</methods>
> 
> Presumably this is the same as the service sometimes called 
> Push-to-Talk (PTT, PoC). The concrete problem is that there 
> are several _non-interworking_ variants of this service, that 
> still all would match the characteristics listed above, as 
> the _SIP_ part might still be standard, at least for some 
> methods etc. But still the communication would fail even if 
> the tuple looks OK.
I don't think I understand you here. I would expect that if both end-point
SIP US support exactly the same methods, the SIP UA should also be able to
handle those SIP method. Or, to phase it in another way, both end-point
should be able to communicate with each other only based on using these
capabilities.

> (Also if I saw the characteristics above, 
> I could as well determine that they describe normal VoIP 
> application running in (very) some old PC with half-duplex 
> audio drivers, so I claim the service description is hard to 
> make unambiguous in the first place.)  
>
I also have the impression that it will be difficult to determine the
services merely based on the SIP methods (and ...) supported by the SIP UA.
It possibly might mean that the SIP-based ptt-service on my mobile phone
might be mapped onto some communication service on your PC. Then, I wonder
who will be responsible for such kind of mapping? Only the end terminals, or
is support from the network, presence server, necessary? And, how will one
service in one domain be mapped into a service in another domain? I believe
there are some open issues here. 
   
> I think the main point of a service tuple is to give the 
> watcher enough information to know whether he can really 
> communicate & interoperate with the advertised service. Given 
> that many services taht are using SIP also have propritary or 
> non-SIP features, I don't think the current approach is enough. 
> 
Do you have an example of a service that uses SIP and also has non
SIP-features? If your service also uses non-SIP features, you can not
determine the type of service by only looking at the SIP capabilities
supported by the SIP UA. Some indication of that non-SIP feature should also
be present in the presence document. 

> Of course each of these proprietary services are allowed to 
> define additional status or tuple-level extensions to PIDF.
Yes, you can always extend the PIDF. My comment here is that this might lead
to an "explosion" of applications or services. It will certainly not help
interoperability.
 
> However, I would like to have some kind of "service 
> identifier" as part of the basic framework so that this could 
> be done in a consistent manner. I think it would help 
> especially in making of authorization and composition rules 
> more simple. The current "class" attribute is way too loosely defined.
> 
> So the concrete proposal is to include in RPID a "service id" 
> element that would have a vendor-specific namespace, similar 
> to e.g. vendor-specific XCAP AUIDs. So for instance the 
> SIP-based PTT app from vendor xyz.com would have, e.g. 
> 
> <service-id>com.xyz.ptt</service-id>
> 
> while the PTT app compliant with OMA would have, e.g.
> 
> <service-id>com.openmobilealliance.ptt</service-id>
> 
In general, I could agree with that approach. However, I don't see a reason
why the vendor specific SIP-based PTT should be different from the OMA based
PTT. Simply define one PTT, based on the SIP UA capabilities.

> in _addition_ to describing sip:, half-duplex audio, and the 
> supported methods. Now:
> 1.) Watcher having one of those apps could see right away 
> whether it is possible to communicate
> 2.) Composer getting PUBLISHes from 2 sources could 
> immediately know that they are from a similar app
> 3.) The app could set its authorization rules using the unique id.
> 
> The main downside I can see in this approach that if there 
> are two different proprietary apps that indeed could 
> communicate at least partially, the watcher might make a 
> conclusion that communication is not possible baed on 
> different service-id. However, in this case the watcher still 
> would have the characteristics visible and could determine 
> that some interworking could be achieved. 
Personally, I don't think it is a good idea that an end-user should make
such decission. If I get a presence document that indicates that another
person is able to receive some type of communication, I expect that that
type of communication would actually work when I use it.

>For this kind of 
> reasons there should be careful text about when to use 
> service-id in the first place, and what can be determined from it.
> 
> Does someone think that this is an absolutely bad idea? If 
> so, how would you envision solving the issues discussed above?
> 
I think more care should be taken in mapping SIP UA capabilities into actual
services. That is not so clear to me!

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 16:46:19 -0400

Nancy Greene (QC/EMC) wrote:
> Paul said:
> 
>>I think the real problem in this case is not with the capability 
>>approach. It is that the 'duplex' capability is underspecified. There is 
>>no explanation of how a pair of half duplex endpoints (or one 
>>half-duplex and one full-duplex endpoint) agree on who can talk.
> 
> 
>>the case of the 'voice' capability, it is understood that having both 
>>endpoints support voice isn't enough to support communication. There is 
>>an SDP negotiation of codecs, etc. that either succeeds or fails. There 
>>should be something similar for half-duplex.
> 
> 
> I have been thinking about this too. When it is just a pair of terminals, each could use their own mechanism to not start an RTP session if it detects that the other end has started one first.

If I understand you, that isn't half duplex - it is simplex with the 
direction negotiated. I suppose you could use reinvites to request and 
transfer the floor, but I don't imagine that would work very well.

> But don't we need the duplex info as an attribute in the sdp as well as in a feature tag? It may only apply to one of the media types negotiated.

Probably. Its partially there (in the form of sendonly/recvonly) if you 
want to manage the floor using offer/answer (ugh!). Otherwise something 
else is needed in order to negotiate the need for floor control.

I think the conferencing work also has mechanisms to negotiate the 
establishment of a floor control channel, but I don't think it is SDP.

As long as there is some way of negotiating the floor control in an 
offer/answer, a PTT endpoint can refuse a call that fails to do so. Then 
the incompatibility is comparable to codec incompatibility.

	Paul