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

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

<span style='font-size:10.0pt;
font-family:Arial'>OK – I should stop with that analogy now ;-).

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>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.

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>The agreement in <span
  style='font-size:10.0pt;font-family:Arial'>Boston<font size=2
face=Arial> 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:-

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>‘- The Mixer control command/response messages will be
sent over a reliable connection.

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>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. 

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>This would have the benefit of:-

<span style='font-size:10.0pt;
font-family:Arial'> 

<font size=2
face=Arial>-<font size=1
face="Times New Roman">         
<span style='font-size:
10.0pt;font-family:Arial'>reliable message exchange

<font size=2
face=Arial>-<font size=1
face="Times New Roman">         
<span style='font-size:
10.0pt;font-family:Arial'>clean, light weight protocol message (no need for
mandatory SIP headers)

<font size=2
face=Arial>-<font size=1
face="Times New Roman">         
<span style='font-size:
10.0pt;font-family:Arial'>No need for control messages to traverse SIP signaling
path

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>Just interested in your opinions on this topic and to
confirm what many of you already know – that I am completely loopy. 
While only a small requirement, its impact would be far reaching as far as the architectural
direction.

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>Best Regards,

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>Chris.

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'> 

<span style='font-size:10.0pt;
font-family:Arial'>  

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.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Jan 2005 15:42:54 GMT

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:-
>  
> ?- 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?
SIP is a reliable connection so I don't think this rules out SIP b

> 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.