Subject: RE: [Sipping] Re: I-DACTION:draft-loreto-sipping-dialog-correlation-00.txt

From: "Even, Roni" <[email-masked]>
Date: Fri, 24 Mar 2006 20:59:53 +0200

Paul,
Thanks for the drawing, this makes it clearer. I agree that (2) is better and a standard way to do it will be good (I think MBUS is Informational). 

Yet I think both will work and for both 3PCC will need to be clearly defined so that the controller may be able, for example, to transfer A while keeping C in the call or to transfer both.

I think that (2) will also work better for the static case where the A to C connection is established on power up for example so A can show that it supports both audio and video which is not the case in (1)

Roni Even

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, March 24, 2006 8:25 PM
> To: Adam Roach
> Cc: Even, Roni; sipping; Gonzalo Camarillo
> Subject: Re: [Sipping] Re: I-DACTION:draft-loreto-sipping-dialog-
> correlation-00.txt
> 
> We can get hung up on what protocols are used, but fundamentally there
> are two different architectures for this situation:
> 
> 1)	A ------------------ B
> 	                     |
> 	C -------------------|
> 
> 2)	A ------------------ B
> 	|
> 	C
> 
> In the above, A is the node that wants to use a camera, C is the camera,
> and B is the other participant in the call, and largely a passive
> bystander.
> 
> It is architecture (1) that is advocated by this draft. I have suggested
> that (2) is a better architecture that can be achieved using sip 3pcc.
> Adam is, I think, suggesting (2) using mbus for the A-C link.
> 
> A key difference is how much is expected of B to make this work. I hear
> some say that this is really easy for B to do. But I'm not so sure that
> is true. For instance, suppose that C is included using approach (1),
> and then B decides to transfer "the call" to node D. Is it the
> responsibility of B to transfer both A and C, or only A. If it is
> expected to transfer both A and C, then the complexity for B has been
> increased.
> 
> I also don't see how A uses approach (1) if A and B are in session and B
> sends a reinvite to A proposing to add video to the existing session.
> 
> 	Paul
> 
> 
> Adam Roach wrote:
> > Even, Roni wrote:
> >
> >
> >>Hi Gonzalo,
> >>The example in the email thread
> >>"For example, I walk into a meeting room while talking on my audio-only
> mobile terminal and I want to add video using the fixed camera and large
> screen in the meeting room."
> >>Is a good example. I am aware that using a phone for audio and a
> separate appliance or web camera for video is available in real products.
> The correlation is done in a central entity and you cannot easily achieve
> the scenario you describe in the above example being of ad-hoc
> relationship. The need to the correlation in this case is important, for
> example, for lip-synch or in multipoint for voice activated video switch.
> >>
> >>
> >
> >
> > I think you're right. It sounds like we need "a light-weight
> > message-oriented coordination protocol for group communication between
> > application components." To support this specific use case in a
> > transparent fashion, it sounds like it need to provide "automatic
> > location of communication peers."
> >
> > Text in quotes is not my own. I attribute it to the abstract of
> > http://www.ietf.org/rfc/rfc3259.txt
> >
> > My point being: we solved this problem already. We're hearing from
> > multiple people that we need multi-device coordination. Let's leverage
> > the wheel that we've already invented instead of starting from scratch.
> >
> > /a
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> >

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP