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

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Mon, 10 Jan 2005 14:58:54 -0500

OK, OK, stuck my foot in my mouth with the "most" comment.
Still think we should accomodate "legacy" solutions.

dave

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]]
> Sent: Monday, January 10, 2005 10:57 AM
> To: Robert Sparks
> Cc: Paul Kyzivat; Simple WG; Boyer, David G (Dave); Henning 
> Schulzrinne;
> Vijay K. Gurbani
> Subject: Re: [Simple] modeling dispatchers in the data model: 
> a proposal
> formoving forward
> 
> 
> 
> On Jan 10, 2005, at 9:27 AM, Robert Sparks wrote:
> 
> > I disagree with the "most" below.
> >
> Me too. We need to be looking forward, not backward.
> 
> > Most of the systems capable of video I've seen deal
> > with reINVITEs that add/remove video streams independently
> > from audio. Some even start with no video by default.
> >
> > RjS
> >
> > On Jan 9, 2005, at 6:54 PM, Boyer, David G ((Dave)) wrote:
> >
> >> Henning,
> >>
> >> I was refering to what is primarily available in 
> commerical systems,
> >> which
> >> dispatchers will have to support.  I know systems have 
> been developed
> >> that support adding media dynamically, the point is there 
> are systems
> >> (most commercial
> >> systems) that do not support this type of re-INVITE.
> >>
> >> Dave
> >>
> >>> -----Original Message-----
> >>> From: Henning Schulzrinne [mailto:[email-masked]]
> >>> Sent: Saturday, January 08, 2005 5:53 PM
> >>> To: Boyer, David G (Dave)
> >>> Cc: Paul Kyzivat; Vijay K. Gurbani; Simple WG
> >>> Subject: Re: [Simple] modeling dispatchers in the data model:
> >>> a proposal formoving forward
> >>>
> >>>
> >>>
> >>>> 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
> >>>
> >>> 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.
> >>>
> >>>
> >>>> 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).
> >>>
> >>> 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...)
> >>>
> >>>
> >>>> Anyway, these are two distinct services and should be in 
> two tuples.
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Simple mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/simple
> >
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: [email-masked]
> 

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

---

From: [email-masked]
Date: Mon, 17 Jan 2005 23:54:34 +0200

Hi,

Paul Kyzivat wrote:
> 
> Jonathan Rosenberg wrote:
> > inline. I'd ask folks to please read to the end where I 
> have another 
> > compromise proposal on unique URI that may be more 
> palatable than my 
> > previous one.
> 
> I *think* I'm ok with this, as long as it is specified that <contact> 
> and <i-belong-to> are mutually exclusive.
> 

A basic question: In case we have a GRUU in the contact, is there some use for also telling what the AoR is within the tuple? If yes, <i-belong-to> in addition to <contact> would be useful, otherwise Paul's suggestion for keeping these mutually exclusive works. I don't know, but I remember some discussion on problems with GRUUs in call logs. 

In either case, I think <i-belong-to> should be accompanied with an instance id, so that the combination of the <i-belong-to> and the id would be unique in the same way as the <contact> is supposed to be in the current data model. That would help doing authorizations. Now we have <uri> and <uri-scheme> in presence-rules to match tuples. I propose changing these to <contact-uri> and <contact-uri-scheme> and adding <i-belong-to-uri-scheme> and <i-belong-to-id> (or along those lines). Also, the id would help in deciding override vs. union between tuples, and further along the path if we do configurable composition policies. I don't there's ever been a question whether a tuple should have these kind of unique keys, the argument has just been about whether contact can be such. I hope we can conclude that we do both ways.

Markus