Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI)

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Feb 2005 10:49:14 -0500

I think we are still talking past one another. I think Doom and PTT are 
very different in character from one another. So lets talk about them 
separately.

I can imagine several ways that the Doom stuff might work:

Doom-1) There is a Doom game server somewhere. (Something like a 
conference focus.) To use it you call it, establishing audio, video, and 
doom-control-protocol media streams. The audio and video you receive are 
a rendering of the game.

Doom-2) You and your friends have sip-enabled Doom game consoles. You 
can connect them via a sip call, establishing audio, video, and 
doom-control-protocol media streams. The audio and video you send and 
receive are renderings of some/all of the game.

Doom-3) You and your friends have sip-enabled Doom game consoles. You 
can connect them via a sip call, establishing audio, and/or 
doom-control-protocol media streams. Only the doom-control-protocol is 
strongly related to doom. The two game consoles use it to synchronize 
state, and each then renders the game to its user. The audio stream, if 
present, just lets the players communicate directly via voice - the 
audio is mixed with the game audio at each end. If this device is called 
and doom-control-protocol is not negotiated, but voice is, then the game 
machine simply acts as an audio phone.

I can imagine Doom-1, but don't think it is a great model. Having the 
server do the audio and video rendering for all the users isn't 
consistent with the way games usually work. If you were to follow this 
model, then the game server would probably be represented as an AoR. 
Presence would be possible but not especially interesting.

I have difficulty seeing how Doom-2 would work, since each game console 
probably want to do its own rendering of the game. At best this would 
require that they negotiate and pick one to do the rendering, and the 
other to be a slave. IF this was the model, then I agree that the entire 
combination needs to be understood as a unit, as Brian suggests.

The model in Doom-3 makes more sense to me. And not surprisingly it fits 
with my capability model of representing presence. The 
doom-control-protocol is the only part that is doom specific. This model 
also can be used with a conference server to support multiplayer games 
in a way that is more plausible than Doom-1.

More below.

Brian Rosen wrote:
> I don't think we have a prayer of making a Doom game with audio and video
> streams as well as the game stream work in presence without having a notion
> of service that has some kind of name which is used to describe the service.
> That service description can be text as long as it is unique enough that the
> watcher (client) can render some good enough UI and the watcher (human)
> understands what to do with it.

What you describe is true for Doom-2. For Doom-1 the entire presentity 
represents the "service". And Doom-3 doesn't require a separate service.

> So if someone defines "Doom" as being a service that has a game stream and
> optional audio and video streams, then you can build a watcher that
> understands what Doom is and render a very nice interface with, say, a Doom
> icon, and a basic watcher can show the name of the service and the media
> streams on it that a human can interpret it.  I think we all agree that, at
> the very least, the presence of the Doom service is contained in one tuple.
> The only thing you really would like to understand about service is name and
> the fact that it can contain multiple streams and multiple capabilities.  
> 
> I don't think you can infer this notion of service from the aggregate of
> capabilities, and I don't want to try.  You can DEFINE a service as having
> some fixed and optional capabilities with the watcher being able to discover
> which of them a particular presentity has available at a point in time.
> That we can do.  So don't guess that audio and/or video with half duplex and
> floor control MEANS PTT, instead DEFINE PTT as a service that has audio,
> optional video, half duplex and floor control and let a tuple state that the
> presentity supports a PTT service and at the present time only has audio
> (not video) available. 

I don't get this. The floor control is the essence of PTT. Otherwise it 
is just audio. As Jonathan has pointed out, this may be a case where the 
implementation won't allow you to negotiate a session without the floor 
control. If so we need some way to indicate that. But that is the only 
special thing.

> Then I can offer a Telephone service and Doom service, both of which support
> audio, and we won't get anyone confused.

I'm still seeing it differently, because I think Doom-2 is the only 
plausible model. Which model of Doom do you have in mind?

	Paul

> Brian	
> 
> 
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:[email-masked]]
>>Sent: Tuesday, February 01, 2005 1:51 PM
>>To: Brian Rosen
>>Cc: 'Aki Niemi'; 'Simple WG'
>>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try
>>atdata model compromise regarding unique service URI)
>>
>>Brian - inline.
>>
>>	Paul
>>
>>Brian Rosen wrote:
>>
>>>I've pretty much stayed out of this whole set of threads, but this one
>>>really had me wondering where everyone's head is again.
>>>
>>>We're getting wrapped around the axle of not having a definition of
>>>"service" again.
>>
>>Well, we had decided that a service is whatever a tuple describes.
>>But functionally I agree it has still not really been resolved.
>>
>>
>>>Specifically, I believe that the Doom case you describe below is a
>>
>>Service
>>
>>>called Doom that has a number of media streams it supports.  It does NOT
>>>offer a voice SERVICE, the DOOM service includes game, audio and video
>>
>>media
>>
>>>capability.
>>
>>I infer that you are using "service" to denote what kind of
>>functionality is provided via the communication channel(s) described.
>>
>>So in this case there is an automaton executing the Doom game, providing
>>a rendering of that via the output streams, and accepting input to it
>>via the input streams.
>>
>>
>>>Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly
>>>using the same hardware, possibly not.  You don't care.
>>
>>We currently have no definition of, or way to describe, services such as
>>these. The closest we can get to this right now is via a few attributes:
>>
>>- automaton
>>- attendant
>>- message-taker
>>
>>If all of those are false, in absence of any extentions, I think you
>>have a "conversational" service facilitating interactive conversation
>>with a human being.
>>
>>Even with the limited range of "service"s that can be represented via
>>those attributes, it is impossible to say in a single tuple that you
>>have a conversational service and an automated message taking service,
>>except in the negative - by saying nothing about what is provided.
>>
>>
>>>PTT is a SERVICE.  It supports voice, possibly video and has floor
>>
>>control.
>>
>> From what I have inferred above, I don't see how this can be considered
>>a service. It says nothing about the content, and its not an automaton.
>>It simply provides different ways to control the media in a
>>conversational session - like a different codec does.
>>
>>
>>>But there is nothing in the set of capabilities such as: audio=true,
>>>video=false, duplex=full, floor-control=false that could possibly
>>
>>indicates
>>
>>>PTT isn't there.  A dumb but straightforward audio conference phone
>>
>>could
>>
>>>have exactly the same capabilities.  The dumb conference phone could
>>
>>have
>>
>>>that also.  The "floor control=true" and "duplex=half" capabilities, in
>>>particular, are not peculiar to PTT.  A cell phone with PTT today would
>>
>>have
>>
>>>at least two services (voice and PTT).  Today, those services are
>>
>>separate;
>>
>>>even the voice path is separate in many implementations.
>>
>>Why is this any different than audio vs video? I might want to have a
>>conversation with you using any of those, and switch back and forth
>>between them during the call. I think I know the answer, but its not an
>>appealing one - the UA will simply not permit mixing the capabilities in
>>a single call, or even switching among them serially within a call. Of
>>course there are lots of technological excuses for this, but it makes no
>>real sense from a user standpoint.
>>
>>I can at least imagine using PTT to talk to a VM "service" or auto
>>attendant "service". This all suggests to me that PTT is not a service
>>in the sense that Doom might me.
>>
>>The PTT case is, I think, just a matter of wanting a way to describe
>>mutually exclusive combinations of capabilities. I believe we agreed
>>some weeks ago that this was potentially still of interest, but
>>postponed dealing with it. Until then, multiple tuples with the same
>>contact provides a way at the expense of being ambiguous about what is
>>intended.
>>
>>I have been trying for years now to understand what you "service"
>>oriented people are talking about. It always seems like there is
>>*something* there, but its elusive, and you don't all seem to have the
>>same concept. I think there may be some opportunity to describe this as
>>the behavior behind the media, encompassing VM, Attendant, Doom.
>>
>>
>>>And please keep in mind that I want to be able to offer a presence
>>
>>service
>>
>>>with ONE contact, which I assumed was one tuple, but don't care if there
>>
>>are
>>
>>>multiple tuples as long as they have the same contact URI.  That
>>
>>represents
>>
>>>the presence information of the presentity, full stop, including all of
>>
>>the
>>
>>>services it might support.
>>
>>You have been quiet for so long now that I thought you had got the
>>correct religion, or fallen asleep, or something. :-)
>>
>>If you are going to offer a single tuple, and hide both a conversational
>>voice service and Doom behind it, I don't see how you are going to avoid
>>  disappointing someone. Somebody is going to end up on their phone
>>talking to a doom game.
>>
>>
>>>Brian
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>Of Paul Kyzivat
>>>>Sent: Tuesday, February 01, 2005 9:58 AM
>>>>To: Aki Niemi
>>>>Cc: Simple WG
>>>>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try
>>>>atdata model compromise regarding unique service URI)
>>>>
>>>>
>>>>
>>>>Aki Niemi wrote:
>>>>
>>>>
>>>>>ext Paul Kyzivat wrote:
>>>>>
>>>>>...snip...
>>>>>
>>>>>
>>>>>
>>>>>>For devices with the real estate, it would be better to simply display
>>>>>>multiple icons for each buddy indicating what capabilities are
>>>>>>currently available. (Perhaps icons of phones and cameras can turn
>>>>>
>>>>>>from red to green.)
>>>>>
>>>>>I don't buy this. Think of a "doom" icon that can be either red, green,
>>>>>or  indicate deathmatch. Capabilities are uninportant, it's the service
>>>>>that is composed of those capabilities that is important.
>>>>
>>>>I don't understand your point at all.
>>>>
>>>>It seems to me that either:
>>>>
>>>>- you have a separate tuple/service for Doom, with its own unique
>>>>  contact that I can call. In this case doom itself may have
>>>>  "doom" capability, and perhaps audio, video, etc. as well.
>>>>
>>>>  you then have other contacts with differing sets of capabilities
>>>>  and different contact addresses. Perhaps one with basic voice.
>>>>
>>>>- you have a single multipurpose tuple/service. It has capabilities
>>>>  for voice, and maybe doom as well.
>>>>
>>>>- you have multiple tuples - one for doom, another for basic voice,
>>>>  but they share a contact address.
>>>>
>>>>The question is, how do I know what to expect when making a call in each
>>>>case? E.g. if I make a voice-only call, do I talk to you, or do I hear
>>>>the audio from a doom game I can't control?
>>>>
>>>>I guess it depends a bit on how you expect doom to work. Do you imagine
>>>>it to consist of a game control protocol plus audio and video streams
>>>>rendering the game?
>>>>
>>>>
>>>>
>>>>>And do you really think users will generally be happy to interpret that
>>>>>someone is available for push-to-talk by examining a set of three (or
>>>>>more) icons?
>>>>
>>>>I see a couple of alternatives here:
>>>>
>>>>- the user has a PTT application displaying presence. It is only
>>>>  interested in PTT, so it filters what it displays. All I get is a
>>>>  list of buddies with red or green status.
>>>>
>>>>- the user has a general purpose presence client, that can do PTT,
>>>>  regular voice, video, Doom, whatever. (The user has to both pick
>>>>  a buddy and then pick an action to do something.)
>>>>
>>>>  In this case, it has three or more things to display regardless
>>>>  of how the RPID document is formatted. Either it has multiple
>>>>  capabilities for a single tuple, or it has multiple tuples each
>>>>  with (potentially multiple) capabilities. There are many ways
>>>>  of rendering each of these, but the fundamental complexity of
>>>>  what is to be rendered is pretty much the same.
>>>>
>>>>
>>>>
>>>>>>You seem to have in mind a "video service" that includes both voice
>>>>>>and video, and a separate "audio service" that includes only audio.
>>>>>>And then either or both can be available.
>>>>>
>>>>>
>>>>>I gave an example of *three* different services. But fine, let's say
>>>>
>>you
>>
>>>>>only have two: a videophone capable of both video and audio (together
>>>>
>>or
>>
>>>>>separate) and a push-to-talk client (audio, half-duplex and floor
>>>>>control). Now, let's say video is unavailable, audio is available, and
>>>>>push-to-talk is unavailable.
>>>>>
>>>>>How would you represent that in a single tuple?
>>>>
>>>>I left out the PTT to keep things simple, since I don't think we have
>>>>agreed in detail how to represent it as a capability. But lets try
>>>
>>anyway.
>>
>>>>In the state you describe it, I would simply represent it as a tuple
>>>>with audio=true, video=false, duplex=full, floor-control=false. What is
>>>>so hard about that?
>>>>
>>>>
>>>>
>>>>>>But how is this better (or even as good as) a single videophone
>>>>>>service that is capable of supporting both voice and video, or just
>>>>>>voice, or just video, depending on what is negotiated in a call? With
>>>>>>such a service, if I don't want to be available for video, I just
>>>>>>disable it, so it won't be offered or answered, and then video then
>>>>>>isn't advertised in the (single) presence tuple either.
>>>>>
>>>>>
>>>>>I'm not going to debate over details about voice and/or video. My
>>>>>attempt was to demonstrate that there are "services" that aren't going
>>>>>to be described only using a single, simple media attribute, like
>>>>>"voice" and "video", but will be composed of a set of capabilities,
>>>>>where this capability set then shares a status that will have more
>>>>>states available than simple on or off.
>>>>
>>>>Ahh. This may be hinting at the real issue. But it is only a hint, and I
>>>>think you need to say a lot more to establish the use case. I've got a
>>>>feeling that PTT is a bad example because its "differences" are more
>>>>about limitations in the technology that intrinsic feature differences.
>>>>
>>>>I suspect Doom may be a better example. I have the idea that what you
>>>>have in mind is that when I call the "Doom Service" I get audio and
>>>>video that are slaved to the game, rather than a conversational adjunct
>>>>to the game that allows me to converse with the other player(s) while
>>>>playing. If so, then it is a lot like an IVR or a VM server. If so, then
>>>>I agree with you that it *should* be represented as a separate tuple.
>>>>But I also think it *should* have a separate contact, so that it is
>>>>clear how to reach that particular service.
>>>>
>>>>I gather you have in mind that if I negotiate the doom control protocol
>>>>I will get the doom service and the audio/video will be slaved to it,
>>>>but if I don't negotiate the doom control protocol then I get the
>>>>"conversational" service managing my voice/video. I don't see why I
>>>>would be able to draw that conclusion from the RPID.
>>>>
>>>>
>>>>
>>>>>However, stepping back for a moment.
>>>>>
>>>>>Seems there is still some fundamental desire here to restrict the
>>>>>presence data model to suit the "unique-URI" concept.
>>>>>
>>>>>But like Henning has pointed out many times before, there will be
>>>>>multiple tuples in a document. So inherently, the watcher is faced with
>>>>>having to make a selection. Henning has also pointed out that to
>>>>>determine uniqueness, the contact is a very poor key to use. Whether
>>>>>some of those tuples have the contact address is therefore immaterial
>>>>>(and depends exclusively on the uniqueness rules of the URI scheme).
>>>>>Also, we aren't going to forbid a dumb composer passing all of the
>>>>>received tuples to the watcher using the union composition.
>>>>
>>>>In most cases I see no reason why the watcher has a need to determine
>>>>uniqueness. All it has to do is present the alternatives to the user,
>>>>let the user choose one, and send a request to the contact of the one
>>>>chosen. The kind of request sent can either be determined by default
>>>>based on capabilities advertised in the tuple and local capabilities, or
>>>>can be adjusted based on explicit choices made by the user.
>>>>
>>>>
>>>>
>>>>>If we were to *mandate* that all SIP-enabled services are represented
>>>>>using a single tuple, where would you enforce this rule? And what would
>>>>>be the benefit compared to allowing more than a single tuple?
>>>>
>>>>I'm not sure this is something to mandate. I think it is more of a "best
>>>>practices" kind of thing. It seems clear that people are going to do a
>>>>bunch of weird things, and results will vary. About all we can do is
>>>>give suggestions on how to get a good result.
>>>>
>>>>
>>>>
>>>>>Simply saying that it is possible in some instances to do things that
>>>>>way is not a good enough reason, if there are instances where it does
>>>>>not work.
>>>>
>>>>I think this might best be approached by restarting the work on presence
>>>>use cases.
>>>>
>>>>Here is (a bad) one, based on what I think you have in mind. (Please
>>>>feel free to provide a better way to handle this case.)
>>>>
>>>>Suppose your presence includes one tuple listing audio, video, and doom.
>>>>My presence client doesn't understand doom or video, so it simply
>>>>renders the tuple as available for voice. I pick it and make a voice
>>>>call. Your Doom service slaves audio to the game, so I just hear a bunch
>>>>of bleeps and gun fire. I am likely to be annoyed with you for having
>>>>announced that you were available for voice when you were not.
>>>>
>>>>Or, your UA refused my call because I didn't offer doom control
>>>>protocol. I'm still annoyed that you said you were available for voice
>>>>but refused my call. (But at least this is within the realm of
>>>>reasonable behaviors.)
>>>>
>>>>	Paul
>>>>
>>>>
>>>>_______________________________________________
>>>>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: "Brian Rosen" <[email-masked]>
Date: Wed, 2 Feb 2005 23:15:14 -0500

I think the basic model is close to Doom-3, but a bit different from what
you describe it.  It's not Doom-1 or 2.

First of all, the audio and video in a Doom game that are the actual Doom
visual and auditory outputs of the game are locally generated.  The Doom
control protocol is all that is needed for the basic game.

I think if there is audio, it's a conference call-like open audio channel
between players.  As in Doom-3, it would be locally mixed with the local
Doom game sounds.  It could have PTT, it could have a notion of "side" (ie
normally I talk to only my side, but I have a floor that lets me talk to all
the players), but it's defined by the Doom game what it does and how you use
it.  It's not a general purpose telephone, and it's unlikely to be precisely
the mobile guy's notion of PTT.  That's what I would do.  Someone else may
define it differently.  However it's defined, it's an audio service
specifically specified for Doom.  The audio and game control are intertwined
into the Doom service.  You can't infer how it works; you need to read the
description of it in the Doom service.  Probably, someone wrote a spec for
it and published it.  Probably, they registered the service name with IANA.
That lets multiple implementations of the client exist and interoperate. You
don't know, for example, unless you understand the Doom service, if it makes
any sense to run the Doom game stream without the audio or vice versa.

> control. If so we need some way to indicate that. But that is the only
Nope, floor control is not the "essence" of PTT, it's just one of its common
characteristics.  You can have floor control without PTT.  You actually can
have PTT without floor control; a real radio system is PTT without floor
control -- you push the button and talk -- if two people do it at the same
time, third parties hear one or both, and the two speakers don't hear each
other.  Some PTTs assume half duplex, others don't.  You can define a PTT
service that is half duplex, and another that is half or full duplex.  There
isn't going to be ONE PTT service, their probably will be more than one.

Brian