Subject: SIP vs. Connection-Oriented Transports (was RE: [mediactrl] MediaCtrl Comments - overall summary of our comments)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 14 Feb 2006 18:23:33 GMT

There was a place for SIP-based transport.  It was there, it was easy, it works, and it in real (but not all) network topologies is good.

Moving in to the future, we cannot do both SIP transport and connection-oriented.  We must chose one or the other.  Using a connection-oriented transport is a goal in itself.  If one recalls, it is the reason we sent Chris and Tim off to write the Framework in the first place.

I am not suggesting the question is closed.  We do need to nail that down, however, pretty quickly. 

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: Monday, February 13, 2006 5:28 AM
To: Adnan Saleem; [email-masked]
Subject: RE: [mediactrl] MediaCtrl Comments - overall summary of our comments

Adnan,
Some thoughts and comments.
Chris.
 
However, as noted in earlier comments posted for framework ID, we believe that stipulating a TCP only control channel is too restrictive. Ability to negotiate a TCP or SIP/INFO based communication interface between AS and MS is more flexible provides framework.
[cjb] OK - flexible framework for what?  The sole purpose of this doc is to provide a 'generic' framework that allows control using a reliable channel (see abstract).  In true IETF style it does not try to solve the worlds media server problems.  'Yes' - it is intended to be used for media server control BUT this could be one of many potential usages.  I don't feel we can just shoe horn a secondary mechanism into the document that is intended to specify a 'Generic Control Channel' mechanism. 
 It is understood that SIP control interface does impose certain restrictions, such as message fragmentation and network traversals etc,
[cjb] Agreed - hence the specification.
 however it also does provide several key advantages in terms of SIP stack re-usability and simpler and more readily available interface, just to name a few.
[cjb] BUT one (using SIP INFO in such a manner) that historically WILL NOT be standardized by the IETF + for all the positives there is an equal number of negatives
 This is evident by the large scale current deployments, where SIP is the choice for control interface. The framework itself should not make this choice, rather facilitate the negotiation.
[cjb] Strongly disagree - as mentioned earlier, the purpose of the framework is to provide a reliable control channel leveraging SIP properties.  I am strongly against wavering from this requirement.  If another mechanism is required then I personally think it needs to be standardized in another documents - maybe at a later date
 
Chris.

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