Subject: [mediactrl] Framework: Transport Protocol

From: "Burger, Eric" <[email-masked]>
Date: Wed, 15 Feb 2006 07:33:06 GMT

This is from Section 7.1.

I don't get the keep-alive mechanism (from the draft) or serialization
(from Adnand's comments) from the REPORT message.

A reliable, connection-oriented protocol is required by the draft.  Why
are we requiring a reliable, connection-oriented protocol if we build
connection management into the protocol?  I am not advocating running
the protocol over UDP.  I am advocating using the connection management
facilities offered by the transport protocol.

TCP, SCTP, and TLS are done.  We do not need to rebuild them here.
[Unless the goal is to rebuild Q.1244 or SR-3511.] 

--------------------------
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: "Chris Boulton" <[email-masked]>
Date: Wed, 15 Feb 2006 08:16:16 GMT

[cjb] Let me give you the motivation as I am keen for some advice on
this.  The REPORT message was used for the case where the entity acting
as the UAS on the control channel disappears.  The client has a
transaction timeout and if no REPORT is received in that period - it is
considered dead.

Why are we requiring a reliable, connection-oriented protocol if we
build connection management into the protocol?

[cjb] It was aimed more at transaction management at the Control channel
level rather than connection management. E.g. I send an XML blob of some
sort that consists of a series of commands to be executed at the far end
(which will be reported subsequently in REPORT messages).  So the client
gets a 202 and waits for the results of the commands it has issued.  How
long does it wait?  What if it receives nothing?  The 'idea' was to give
the guy issuing the command a time limit that if it has not received
anything (hence the refresh REPORT) then something has gone wrong.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.