Subject: RE: [Simple] modeling dispatchers in the data model: a proposal formoving forward

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Fri, 7 Jan 2005 23:05:58 -0500

Paul,

Comments inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, January 07, 2005 6:20 PM
> To: Vijay K. Gurbani
> Cc: Simple WG
> Subject: Re: [Simple] modeling dispatchers in the data model: 
> a proposal formoving forward
> 
> 
> 
> 
> Vijay K. Gurbani wrote:
> > Paul Kyzivat wrote:
> > [...]
> > 
> >> I have a feeling we are talking past one another.
> > 
> > 
> > Paul:
> > 
> > The crux of the matter is single tuple or multiple tuples 
> to represent 
> > discrete services accessible through the same Contact URI.  I favor 
> > having multiple tuples with attributes defining the 
> characteristics of 
> > the service; each such tuple has the same Contact URI (instead of a 
> > GRUU).  But as I understand it, there isn't consensus since you may 
> > favor a single tuple for all services accessible through the
> > same Contact URI.
> 
> If there are discrete services available thru the same 
> contact URI than 
> I agree with representing them as distinct tuples.
> 
> The difference of opinion is when there are two services and 
> when there 
> is one service with multiple capabilities. Some examples:
> 
> 1) a video phone. It has both audio and video capabilities. It is 
> possible to use either or both in a single session. It is 
> also possible 
> to start with just voice and then add video later in the session. I 
> think this is one service with one tuple.
> 
Most video phones code the audio and video together - can't usually
start with audio and add video.  You can start with an audio conference
and then go to a video conference but this is a different case.  Some
systems, as you mention below, allow this separation - not sure how
useful
this is because of the different delays in the transmitted audio and 
video streams (lip sync problems).
Anyway, these are two distinct services and should be in two tuples.

> 2) same as (1), but I have disabled the video feature. It is 
> still one 
> service, one tuple, now the video capability is indicated as absent.

I think this would then just be an audio service.
> 
> 3) a sip communicator client on a pc. supports voice, video, 
> and session 
> mode IM via MSRP. Any combination of these can be used in a single 
> session. Still one service, one tuple.

>From the user perspective I can see how this would be viewed as a single
service (the web collaboration environment supports all of these 
communication modalities).  You may  have a conference where not all
of the modalities are active, but the unused modalities would not be
available for another session from within the sip communicator client.
> 
> 4) a sip communicator client on a pc. Supports voice, video, 
> page mode 
> IM. Permits any combination of voice and video in a session. Permits 
> MESSAGE only outside a dialog. The UI for IM is separate from 
> the UI for 
> voice/video. This is two services - one for voice & video, 
> another for IM.

This one confuses me.  If the IM pager has a distinct interface, how is
it part of the sip communicator client?  In 3 if the IM chat session
is undockable with unique session controls (start / stop IM session)
does
that mean it would be represented as a distinct tuple?
> 
> 5) same as (4), but MESSAGE is permitted both in a dialog and 
> outside. 
> MESSAGE in a dialog is integrated with the UI for 
> voice/video. MESSAGE 
> outside a dialog has a separate UI. Not at all clear to me 
> whether this 
> is one service or two. (Best not to build this device.)

I guess I reached a similar conclusion above..

dave

> 
> Do you disagree with the above?
> 
> 	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: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Jan 2005 17:52:33 -0500

> start with audio and add video.  You can start with an audio conference

We've had a system (sipc, http://www.cs.columbia.edu/IRT/sipc) for quite 
a while that can indeed add video at any time, as well as any other 
supported medium. This is a standard re-INVITE scenario.

> video streams (lip sync problems).

While we don't do this, rat and vic have had the ability to lip-sync 
across independent applications since the mid-90s. (That said, I suspect 
that few combined systems do real lip-sync...)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jan 2005 10:52:31 -0500

Dave - comments inline. Extraneous material edited out.

	Paul

Boyer, David G (Dave) wrote:
...
> Comments inline
...
>>>Paul Kyzivat wrote:
...
> Anyway, these are two distinct services and should be in two tuples.

If so, then they will get smarter over time. Lets not assume they will 
stat so dumb.

And hopefully they at least will interoperate with devices that are more 
capable. I trust the phones you refer to will at least *accept* a call 
that offers only audio. Then what will they do if a subsequent reinvite 
offers video as well? (I hope they will accept it if they would have 
accepting it on the initial invite.)

> I think this would then just be an audio service.

Yes, it will probably look like a basic audio service while the video 
feature is disabled, but could dynamically switch to looking like an 
audio+video service when the video is enabled.

It could even look like an audio service to some watchers and an 
audio+video service to others.

> it part of the sip communicator client? 

It would be part of the same "client" because it shares the same 
address. Something at a low level above the sip stack could split these 
things to separarate UIs.

I'm not suggesting this would be a highly desirable way to build 
something, but it seems quite plausible. A MESSAGE based IM client would 
perhaps not use dialogs (because you aren't supposed to use MESSAGE that 
way), and a "regular" voice+video client might not have a UI that is 
suitable for support of message.

In this case it would perhaps be "better" if they had separate contact 
addresses, registrations, and presence tuples. But its not hard to 
imagine someone wanting to circumvent all this "overhead".

 > In 3 if the IM chat session

I don't understand the case you are describing.