Subject: RE: [MEDIACTRL] Control Framework - Issue 1

From: "Braudes, Robert \(Bob\)" <[email-masked]>
Date: Mon, 27 Nov 2006 13:32:47 -0500

Hi Chris,
 
    I agree that this should be OPTIONAL, but I'm not sure that I agree
that it shouldn't be used for co-located AS and MS.  For your other
points, I support this being session-based, with the timeout negotiated
at the start of the session.  There should be a way to renegotiate the
timeout, to avoid unnecessarily dropping calls during periods of
congestion or other resource constraints.  I also agree on having the
negotiation before the channel setup; similarly, using the SIP Control
Framework is preferred over STUN.
 
Bob

  _____  

	From: Chris Boulton [mailto:[email-masked]] 
	Sent: Tuesday, November 21, 2006 5:36 AM
	To: [email-masked]
	Subject: [MEDIACTRL] Control Framework - Issue 1

	Hi All,

	Taking the Control Framework as an independent piece of work
(not media server control specific), I think the next version of the
document should include a 'keep-alive' mechanism.  I fully understand
that in most deployments the AS and the MS using the Control Framework
will be co-located and not require this functionality BUT I feel it is
an important inclusion when looking at the bigger picture (NAT/FW
traversal).  Here are some initial thoughts that would be a good
starting point for discussion:

	-          The mechanism should be OPTIONAL and be negotiated on
initial set-up of the control channel.

	o        I guess it could be switched on/off in subsequent
interactions if required or we could pin it down to the whole session
once negotiated?

	o        The expected keep-alive mechanism timeout period should
also be negotiated.

	o        Any ideas on where to include the negotiation? - I
think it would probably be appropriate in the SIP negotiation before the
channel is even set-up.  This is where we negotiate the Control packages
that are supported so probably this function as well.  It seems a waste
of effort to me to negotiate the packages at the SIP level - then make
the connection only to find out that a required keep-alive is not
supported and you have to tidy up.

	-          How should we construct the keep-alive messages?  I
see 2 options:

	o        Make use of a very lightweight SIP Control Framework
message.  This is my favoured option as I don't want every
implementation that wants to do keep-alive to have to implement a STUN
stack that multiplexes the Control channel.

	o        Use STUN multiplexed over the Control Channel (as has
been used for SIP e.g. Outbound).

	All comments and discussion welcomed to try and help craft this
text over the coming weeks.

	Best Regards,

	Chris.

	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 

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 28 Nov 2006 09:36:44 -0000

[Chris Boulton] Hi Bob - some comments on your comments :-).

Hi Chris,

    I agree that this should be OPTIONAL, but I'm not sure that I agree
that it shouldn't be used for co-located AS and MS.

[Chris Boulton] Totally agrure or distribution is strictly prohibited.&nbsp; If you are not the addressee, please notify the sender immediately and destroy all copies of this email.&nbsp; 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</FONT>
</body>

</html>

------_=_NextPart_001_01C71300.99A1FF12--

--=======93100959=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=======93100959=--

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 28 Nov 2006 09:36:44 -0000

Hi Chris,

[Chris Boulton] Totally agree - the language wouldn't make such
statements.  It would just provide the ability and negotiation
mechanism.

  For your other points, I support this being session-based, with the
timeout negotiated at the start of the session. 

[Chris Boulton] Yes - I intended using the SIP signaling - not sure
exactly what mechanism yet.

 There should be a way to renegotiate the timeout, to avoid
unnecessarily dropping calls during periods of congestion or other
resource constraints.

[Chris Boulton] I would see a SIP Session update (re-INVITE/UPDATE) as
providing the ability to change the timeout period if required.

  I also agree on having the negotiation before the channel setup;
similarly, using the SIP Control Framework is preferred over STUN.

[Chris Boulton] Agreed and Agreed.  I will put some strawman text
together for this section for discussion and post it to the list (and
maybe even a picture for Martin :-)).

Chris.

Bob

  _____  

	Hi All,

	Best Regards,

	Chris.

	

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 Corporee - the language wouldn't make such
statements.  It would just provide the ability and negotiation
mechanism.

  For your other points, I support this being session-based, with the
timeout negotiated at the start of the session. 

[Chris Boulton] Yes - I intended using the SIP signaling - not sure
exactly what mechanism yet.

 There should be a way to renegotiate the timeout, to avoid
unnecessarily dropping calls during periods of congestion or other
resource constraints.

[Chris Boulton] I would see a SIP Session update (re-INVITE/UPDATE) as
providing the ability to change the timeout period if required.

  I also agree on having the negotiation before the channel setup;
similarly, using the SIP Control Framework is preferred over STUN.

[Chris Boulton] Agreed and Agreed.  I will put some strawman text
together for this section for discussion and post it to the list (and
maybe even a picture for Martin :-)).

Chris.

Bob

  _____  

	Hi All,

	Best Regards,

	Chris.

	

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.