Subject: RE: [mediactrl] New version of Control Framework - draft-boulton-sip-control-framework-02

From: "Even, Roni" <[email-masked]>
Date: Wed, 7 Jun 2006 12:02:28 +0100

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>In line

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

<font size=3
face="Times New Roman">

<span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:<font size=2
face=Tahoma> Chris Boulton
[mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006
1:47 PM
To: Even, Roni; [email-masked];
[email-masked]
Subject: RE: [mediactrl] New
version of Control Framework - draft-boulton-sip-control-framework-02

<span style='font-size:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Roni – just some comments [in
red] on your comments – feel free to comment <font size=2
color=navy face=Wingdings><span style='font-size:10.0pt;font-family:Wingdings;
color:navy'>J<span
style='font-size:10.0pt;font-family:Arial;color:navy'>.

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

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

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

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

<font size=3
face="Times New Roman"> 

<font size=2 color=navy
face=Arial>Chris,

<font size=2 color=navy
face=Arial>Some of
my thoughts

<font size=2 color=navy
face=Arial> 

<font size=2 color=blue
face=Arial>  
b) It will be a sizeable topic in its own right, so should be separated out. (Divide
and conquer/manage.)
There may be some implied corollary comments, having to do with how the AS
knows which MS it’s talking to over which control channel, which I
believe is an issue to include and address, but is only necessary with the use
of certain MS resource location approaches and not others.

<font size=2 color=navy
face=Arial> 

<font size=2 color=navy
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:navy;
font-weight:bold;font-style:italic'>[Chris Boulton] Yes – totally
agree.  To be honest you are correct in that this was only ever really
meant to be a placeholder and the intention was that if this work had legs it
would become a separate topic for discussion and documentation.  I can
easily take it out or leave it now that you know it is simply a pointer.

<font size=2 color=navy
face=Arial>[Roni
Even] – Currently we have a framework document and packages which are not
general mechanisms. I think that until we define a different document
structure, we should leave those sections and discuss them. 

<font size=2 color=navy
face=Arial> 

<span
style='font-size:10.0pt;font-family:Arial;color:red;font-weight:bold;
font-style:italic'>[Chris Boulton] OK – I will remove totally from next
version.<span
style='font-size:10.0pt;font-family:Arial;font-weight:bold;font-style:italic'>

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[RE:] I think that those sections should remain as long as
we do not decide on the document structure, the information is required. It has
nothing to do with the next revision<font size=2
color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>

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

<font size=2
color=blue face=Arial><span style='font-size:11.0pt;font-family:Arial;
color:blue'>   A) *Must* the control channel be established before a
call leg is brought to the Media Server? The Control Framework for SIP draft
seems to only talk about setting up the control channel before a call leg is
brought to the MS. It might be useful to allow for both, don’t know
whether it’s problematic. Either way, it should be clarified.

<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'> 

<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>[Chris Boulton] I don’t see
why you MUST have a control channel established.  It would just mean that
you can’t issue any commands on that media stream.  Does that seem
ok to everyone? At the end of the day we are talking about two mechanisms that
are not dependant on each other.   I will clarify the text in the
next revision if no-one opposes.

<font size=2 color=navy
face=Arial>[Roni
Even] My view is that you need to have the control channel established first.
There is a relationship between the control and the call leg. One example is
that the MS may need to convey a conference identifier to be used for
establishing the call leg. In the IVR case you can start with establishing the
call leg and use the dialog identifier to correlate with the control session.
My view is that it will be better to establish the TCP control channel
connection at startup and use it for all sessions. 

<font size=2 color=navy
face=Arial> 

<span
style='font-size:10.0pt;font-family:Arial;color:red;font-weight:bold;
font-style:italic'>[Chris Boulton] OK – but should this be in the
framework?  Remember that the Framework is not supposed to be media server
specific.  Perhaps specific detail like this belongs in the individual
usages of the framework (Packages)  e.g. the IVR package states that a
connection should be initiated – as per ……..<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[RE:] Chris – this is not media server specific but it
defines the flow. The correlation between the Control and SIP call leg is
needed. If you establish the SIP call leg first, you can use the dialog
identifier. If you start with Control first then there is no SIP dialog for the
call leg first. This is not package specific but general mechanism. I was also
stating that for conference you need to have a URI for the SIP call leg, so
maybe the model will be to create the control session start the specific
package and then connect the call leg.

<span
style='font-size:10.0pt;font-family:Arial;color:red;font-weight:bold;
font-style:italic'> .

<font size=2 color=navy
face=Arial> 

<font size=2
color=blue face=Arial><span style='font-size:11.0pt;font-family:Arial;
color:blue'>Or in Garland’s
jargon, a ‘long-lived’ control channel? I believe that would be
desirable to allow for, and should be explicitly addressed.

<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'> 

<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>[Chris Boulton] I will clarify
the text where possible BUT this really is part of a package to make use of the
channel how it wants.  We create a SIP dialog which results in a control
chancel being established – you tear it down the control channel goes as
well.  If in a control package this is long lived then so be it –
just don’t tear down the SIP dialog.

<font size=2 color=navy
face=Arial>[Roni
Even] I do not think this is part of the package to explain the usage of one
control channel. Note that you may have more then one package using the same
channel. 

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'> 

<span
style='font-size:10.0pt;font-family:Arial;color:red;font-weight:bold;
font-style:italic'>[Chris Boulton] Agreed  - I didn’t word that very
well.  It is the intention that a control channel remain until no packages
require it/or closure for some other reason.<font
size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial;font-weight:
bold;font-style:italic'>

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[RE:] What I meant here is that the flow (control or call
leg first) should not be package specific in order to simplify the AS call
flow.<span
style='font-size:10.0pt;font-family:Arial;color:navy'>

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

<font size=2 color=navy
face=Arial>Another
point to consider here is how the AS knows that the MS is up and available for
robustness support, this is not per session issue.  I think that we need
top address the issues of resource management (even a simple one) and
robustness when recommending a flow.

<font size=2 color=navy
face=Arial> 

<span
style='font-size:10.0pt;font-family:Arial;color:red;font-weight:bold;
font-style:italic'>[Chris Boulton] Agreed – and I also think we agreed
this would be separate.<span
style='font-size:10.0pt;font-family:Arial;font-weight:bold;font-style:italic'>

<span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[RE:] I am not sure what should be separate and what should
be included. I think that the framework should address all issues.

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

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

<font size=2 color=navy
face=Arial>Roni
Even

<font size=2 color=navy
face=Arial> 

<span style='font-size:
12.0pt'>

<span
style='font-size:7.5pt;font-family:Verdana'>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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 7 Jun 2006 13:43:16 +0100

I hate to say this -- it sounds too legacy -- but this conversation 
cries out for the development of some abstract 'call flows' (I quote 
because the work goes beyond individual calls) just to see what the 
alternatives are.

Even, Roni wrote:

Chris,

In line

________________________________

From: Chris Boulton [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006 1:47 PM

To: Even, Roni; [email-masked]; [email-masked]
Subject: RE: [mediactrl] New version of Control Framework -
draft-boulton-sip-control-framework-02

Hi Roni - just some comments [in red] on your comments - feel free to
comment :-).

Chris.

Chris,

Some of my thoughts

   b) It will be a sizeable topic in its own right, so should be
separated out. (Divide and conquer/manage.)
There may be some implied corollary comments, having to do with how the
AS knows which MS it's talking to over which control channel, which I
believe is an issue to include and address, but is only necessary with
the use of certain MS resource location approaches and not others.

[Chris Boulton] Yes - totally agree.  To be honest you are correct in
that this was only ever really meant to be a placeholder and the
intention was that if this work had legs it would become a separate
topic for discussion and documentation.  I can easily take it out or
leave it now that you know it is simply a pointer.

[Roni Even] - Currently we have a framework document and packages which
are not general mechanisms. I think that until we define a different
document structure, we should leave those sections and discuss them. 

[Chris Boulton] OK - I will remove totally from next version.

[RE:] I think that those sections should remain as long as we do not
decide on the document structure, the information is required. It has
nothing to do with the next revision

   A) *Must* the control channel be established before a call leg is
brought to the Media Server? The Control Framework for SIP draft seems
to only talk about setting up the control channel before a call leg is
brought to the MS. It might be useful to allow for both, don't know
whether it's problematic. Either way, it should be clarified.

[Chris Boulton] I don't see why you MUST have a control channel
established.  It would just mean that you can't issue any commands on
that media stream.  Does that seem ok to everyone? At the end of the day
we are talking about two mechanisms that are not dependant on each
other.   I will clarify the text in the next revision if no-one opposes.

[Roni Even] My view is that you need to have the control channel
established first. There is a relationship between the control and the
call leg. One example is that the MS may need to convey a conference
identifier to be used for establishing the call leg. In the IVR case you
can start with establishing the call leg and use the dialog identifier
to correlate with the control session. My view is that it will be better
to establish the TCP control channel connection at startup and use it
for all sessions. 

[Chris Boulton] OK - but should this be in the framework?  Remember that
the Framework is not supposed to be media server specific.  Perhaps
specific detail like this belongs in the individual usages of the
framework (Packages)  e.g. the IVR package states that a connection
should be initiated - as per ........

[RE:] Chris - this is not media server specific but it defines the flow.
The correlation between the Control and SIP call leg is needed. If you
establish the SIP call leg first, you can use the dialog identifier. If
you start with Control first then there is no SIP dialog for the call
leg first. This is not package specific but general mechanism. I was
also stating that for conference you need to have a URI for the SIP call
leg, so maybe the model will be to create the control session start the
specific package and then connect the call leg.

 .

Or in Garland's jargon, a 'long-lived' control channel? I believe that
would be desirable to allow for, and should be explicitly addressed.

[Chris Boulton] I will clarify the text where possible BUT this really
is part of a package to make use of the channel how it wants.  We create
a SIP dialog which results in a control chancel being established - you
tear it down the control channel goes as well.  If in a control package
this is long lived then so be it - just don't tear down the SIP dialog.

[Roni Even] I do not think this is part of the package to explain the
usage of one control channel. Note that you may have more then one
package using the same channel. 

[Chris Boulton] Agreed  - I didn't word that very well.  It is the
intention that a control channel remain until no packages require it/or
closure for some other reason.

[RE:] What I meant here is that the flow (control or call leg first)
should not be package specific in order to simplify the AS call flow.

Another point to consider here is how the AS knows that the MS is up and
available for robustness support, this is not per session issue.  I
think that we need top address the issues of resource management (even a
simple one) and robustness when recommending a flow.

[Chris Boulton] Agreed - and I also think we agreed this would be
separate.

[RE:] I am not sure what should be separate and what should be included.
I think that the framework should address all issues.

Roni Even

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 

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