Subject: [mediactrl] Who said you could do that!!!!

From: "Chris Boulton" <[email-masked]>
Date: Tue, 25 Jul 2006 10:25:24 +0100

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>Hi All,

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>As discussed in the ‘Mediactrl’ meeting, thought
I would put a high level straw-man proposal together for the list to discuss. 
The is just a starting point.  The text will centre on using the SIP
INVITE + Control Framework ‘SYNCH’ mechanisms as a means to
exchange a usage token (for inclusion in Section 5 + 6):

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>One of the primary usages of the Control Framework is
to manipulate resources on other network entities, for example SIP media
dialogs on a Media Server.  It needs to be possible to allow only
appropriate control channels to manipulate such resources.  The following text
describes a mechanism that passes a unique token on establishing a control
channel which can then be included in other related events such as the creation
of a SIP media dialog.  A command that arrives on a Control Channel that
is not deemed associated with an associated resource will not be successful. 
When generating the Control Framework ‘SYNCH’ message, the
generating client SHOULD include a ‘Permit-ID’ header which
contains a unique token to identify the control channel being established. 
Similarly, the client responding to the ‘SYNCH’ message SHOULD also
include a ‘Permit-ID’ containing a unique token (TODO - talk about randomness). 
Clients MAY choose not to include a ‘Permit-ID’ header if they have
definitive knowledge that no other entity is capable of issuing un-solicited
Control Framework messages.

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>The Control Framework also defines a SIP ‘Permitted’
header which can be included in requests (such as SIP INVITE) that might be
manipulated by a Control Channel.  This SIP header will contain a comma
separated list of tokens previously negotiated in the previously described
SYNCH interaction explicitly identifying the Control Channels that are
permitted to issue commands that will directly impact associated resources. 
The primary driving use-case would be for a SIP INVITE media dialog to a media
server which would include a list of Control Channels that are permitted to
issue commands such as IVR etc.  If available, the client creating such
associated requests SHOULD include a SIP ‘Permitted’ header
containing authorized control channels.  Clients MAY choose not to include
a ‘Permitted-ID’ header if they have definitive knowledge that no
other entity is capable of issuing un-solicited Control Framework messages.

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>(TODO – update example at the end to include
new mechanism – full media dialog example would be needed in the IVR
package).

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>(TODO – include new error response for Control
Command that does not contain a valid token). 

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>(TODO – talk about REPORT – any impact?).

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>(TODO – BNF for SIP + SCFW).

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

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>All input and suggested text welcome,

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

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

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

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

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: "McGlashan, Scott" <[email-masked]>
Date: Wed, 26 Jul 2006 19:43:50 +0100

<FONT face=Arial 
color=#0000ff size=2>Hi Chris,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Could you also put it in diagram format like the 
others in the minutes? Makes it easier to compare the different approaches. 
Generally, I have a preference for the second approach in the minutes where 
the token is part of the xml commands - could then allow different ASs 
to have different levels of controls, e.g. AS1 only has rights for basic ivr 
cmds whereas AS2 has right to conference creation, etc.
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Scott  

From: Chris Boulton 
[mailto:[email-masked]] Sent: Tuesday, July 25, 2006 
11:29To: [email-masked]: 
McGlashan, Scott; Tim Melanchuk; Asher Shiratzky; Burger, 
EricSubject: Who said you could do that!!!!

<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi All,
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">As discussed in the ‘Mediactrl’ 
meeting, thought I would put a high level straw-man proposal together for the 
list to discuss.  The is just a starting point.  The text will centre 
on using the SIP INVITE + Control Framework ‘SYNCH’ mechanisms as a means to 
exchange a usage token (for inclusion in Section 5 + 6):
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">--------------------------------------------------------------
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">One of the primary usages of the 
Control Framework is to manipulate resources on other network entities, for 
example SIP media dialogs on a Media Server.  It needs to be possible to 
allow only appropriate control channels to manipulate such resources.  The 
following text describes a mechanism that passes a unique token on establishing 
a control channel which can then be included in other related events such as the 
creation of a SIP media dialog.  A command that arrives on a Control 
Channel that is not deemed associated with an associated resource will not be 
successful.  When generating the Control Framework ‘SYNCH’ message, the 
generating client SHOULD include a ‘Permit-ID’ header which contains a unique 
token to identify the control channel being established.  Similarly, the 
client responding to the ‘SYNCH’ message SHOULD also include a ‘Permit-ID’ 
containing a unique token (TODO - talk about randomness).  Clients MAY 
choose not to include a ‘Permit-ID’ header if they have definitive knowledge 
that no other entity is capable of issuing un-solicited Control Framework 
messages.
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The Control Framework also defines a 
SIP ‘Permitted’ header which can be included in requests (such as SIP INVITE) 
that might be manipulated by a Control Channel.  This SIP header will 
contain a comma separated list of tokens previously negotiated in the previously 
described SYNCH interaction explicitly identifying the Control Channels that are 
permitted to issue commands that will directly impact associated 
resources.  The primary driving use-case would be for a SIP INVITE media 
dialog to a media server which would include a list of Control Channels that are 
permitted to issue commands such as IVR etc.  If available, the client 
creating such associated requests SHOULD include a SIP ‘Permitted’ header 
containing authorized control channels.  Clients MAY choose not to include 
a ‘Permitted-ID’ header if they have definitive knowledge that no other entity 
is capable of issuing un-solicited Control Framework messages.
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">(TODO – update example at the end to 
include new mechanism – full media dialog example would be needed in the IVR 
package).
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">(TODO – include new error response 
for Control Command that does not contain a valid token). 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">(TODO – talk about REPORT – any 
impact?).
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">(TODO – BNF for SIP + 
SCFW).
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">--------------------------------------------------------------
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">All input and suggested text 
welcome,
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Chris.
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <FONT 
face=Verdana size=1 colour="#cccccc">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