Subject: RE: [mediactrl] Un-officially running before I can Un-officially walk

From: "Chris Boulton" <[email-masked]>
Date: Tue, 11 Jan 2005 16:07:40 GMT

SIP is a reliable connection so I don't think this rules out SIP b

[Chris Boulton] Agreed - I didn't convey that very well - SIP isn't
ruled out.  I guess that mandating of a transport to override the
default would be possible e.g. always use TLS/TCP/.....

This email and any attached files are confidential and copyright protected.  If you are not the addressee, any dissemination, distribution or copying of this communication is strictly prohibited.  Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Jan 2005 21:41:22 GMT

I do have an opinion on an MRCPv2-style mechanism.  It is really good :)

But seriously, it is good.  It doesn't have the SDP oops of MSRP, it uses
SIP for what SIP is good for (finding servers, load balancing, redundancy),
and it doesn't abuse SIP (routing mixer control commands through proxies
that don't care).

I fully agree that INFO will go away.  Even though we figured out how to fix
the INFO problem in MSCML (i.e., the "What does *this* INFO message
*mean*?"), there is just too much baggage around INFO to think we can keep
using it.

At the very least, it puts MSCML, MOML/MSML, and FluffyML(tm) on the same
footing :)

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, January 11, 2005 11:12 AM
> To: Chris Boulton; MixerControl
> Subject: Re: [mediactrl] Un-officially running before I can
> Un-officially walk 
> 
> 
> On 1/11/05 5:55 AM, "Chris Boulton" <[email-masked]> wrote:
> 
> > OK  I should stop with that analogy now ;-).
> >  
> > Just wanted to bring up a point that I have mentioned to 
> different people in
> > different contexts.  As a disclaimer, I know that some of 
> you will think that
> > I am thinking too far ahead and that we should stick to 
> core requirements on
> > this topic.  I have only mentioned this as I think that it 
> could actually
> > drive some core requirements and I don¹t think it hurts to 
> discuss such ideas.
> >  
> > The agreement in Boston was that we are only really 
> interested in SIP
> > signaling for media mixer control and that we should fully 
> justify our
> > decision not to re-use existing IETF protocols such as 
> H.248  which I fully
> > support.  I would also like a requirement (based on the SIP 
> only decision)
> > that reads something like this:-
> >  
> > OE- The Mixer control command/response messages will be sent 
> over a reliable
> > connection.
> agree
> 
> >  
> > This requirement seems to rule out SIP as the carrying 
> protocol for the mixer
> > control  BUT is that a bad thing?
> > I would see a model very similar to that
> > used by MSRP (I now Tim and myself have put forward ideas 
> like this before)
> > where by the SIP signaling layer is used purely for session 
> initiation and
> > management while an underlying reliable connection 
> exchanges the mixer command
> > set.  The state of the two sessions are inherently linked.
> 
> MRCPv2 which is in many ways the closest thing to what we are 
> talking about
> does this. Eric is the WG Chair of that so he might have thoughts.
> 
> No matter what we say, lots of people are going to send the 
> data in SIP
> INFO. 
> 
> >  
> > This would have the benefit of:-
> >  
> > -         reliable message exchange
> > -         clean, light weight protocol message (no need for 
> mandatory SIP
> > headers)
> > -         No need for control messages to traverse SIP 
> signaling path
> >  
> 
> agree with what you are saying and think this is a good path 
> to think about
> 
> > Just interested in your opinions on this topic and to 
> confirm what many of you
> > already know  that I am completely loopy.
> 
> You may be loopy but I'm afraid you are not going to get to 
> present this as
> evidence of that :-)
> 
> > While only a small requirement, its
> > impact would be far reaching as far as the architectural direction.
> >  
> > Best Regards,
> >  
> > Chris.
> >  
> >  
> >  
> >  
> >   
> > 
> > 
> > This email and any attached files are confidential and 
> copyright protected.
> > If you are not the addressee, any dissemination, 
> distribution or copying of
> > this communication is strictly prohibited.  Unless 
> otherwise expressly agreed
> > in writing, nothing stated in this communication shall be 
> legally binding.
> > 
> 
> 
> 
> Ubiquity Software does not control or endorse the content, 
> messages or information found in this mail list and it 
> specifically disclaims any liability with regard to these 
> communications.
> Ubiquity Software reserves the right the restrict access to 
> any communications in violation of the Terms and Conditions 
> of Use for this website or as otherwise deemed improper.
>