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

From: "Chris Boulton" <[email-masked]>
Date: Thu, 27 Jul 2006 15:34:10 +0100

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Scott – this was an attempt to ‘start’
trying to get some words around the proposals – not really to add a new
one.  I have since realized that this wasn’t very clear and so here
is another attempt at an early straw-man – based on diagram 2 (which is
my preferred choice).  If someone has a major preference for (1) from the
minutes then I think we should work on that text as well.  I have included
the diagram as well for some clarity this time <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:"Courier New"'>UAC                  
AS1                  
MS                   
AS2

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                  
  |                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|Establish Control
Channel                 
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|-------------------->|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|token1              
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|<--------------------|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                     |                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |INVITE
sip:[email-masked]         
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |-------------------->|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                     |

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|INVITE w/ token1    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|-------------------->|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|200 OK (w/
dialog-token)                  
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|<--------------------|                     |

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |200
OK              
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |<--------------------|    
                |                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |ACK                 
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |-------------------->|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|ACK                 
|                     |

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|-------------------->|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|(application dialog,
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
| w/ dialog-token)   
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|.....................|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |               
     |                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|Magic token exchange
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|...........................................|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|(application dialog, |

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
| w/ dialog-token)    |

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|.....................|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                     |

<span
style='font-size:10.0pt;font-family:"Courier New"'> |                    
|                    
|                    
|

<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'>Here is a starter, another very rough
straw-man:-

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

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>One of the primary usages of the SIP Control
Framework is to manipulate associated 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 control channel token
on establishing a control channel which is then included in other related
events such as the creation of a SIP media dialog.  The entity receiving
the SIP INVITE request then includes a unique dialog token in the SIP success
response message.  The two entities involved in the control channel
interaction then both have possession of a ‘Control-token’ and more
importantly a shared ‘Dialog-id- token.  The unique ‘Dialog-id’
token returned is then included in all control framework commands that specifically
operate on such resources.  A driving example being an IVR command being
passed on the control channel directed at a users media dialog (represented by
the ‘Dialog-id’).  The token returned when establishing the control
channel is then included in the SIP media dialog creation.  The 200 OK
then returns the unique dialog-id token that is included in any control framework
messages that operate on the SIP dialog resources.  A command that arrives
on a Control Channel destined for a media dialog that is not deemed associated
with a resource will not be successful.

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>When generating the Control Framework ‘SYNC’
message (on establishing the control channel [ref]), the generating client
SHOULD include a ‘Control-token’ header which contains a unique
token to identify the control channel being established (TODO - talk about
randomness).  Clients MAY choose not to include a ‘Control-token’
header if they have definitive knowledge that no other entity is capable of
issuing un-solicited Control Framework messages.  A client receiving a ‘SYNC’
message that does not contain ‘Control-token’ and has policy that
insists on using this mechanism can respond with an xxx error response.

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

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>When forwarding a dialog request (such as a users
media dialog) to a client with an established control channel that has an
associated ‘Control-token’, a SIP ‘Control-token’
header MUST be included.  If not present and a ‘Control-token’
exists for the association (as determined by control channel set-up), the
request should be rejected (TODO – using what?  New response code –
xxx ‘No Security association’).  If the entity receiving the
request locates the SIP ‘Control-token’ header but does not have
knowledge of the token value, the request MUST also be rejected (TODO –
using the previous response).  If the value contained in the ‘Control-token’
header is valid and the request is a success, the responding client MUST
include a SIP ‘Dialog-token’ header which contains a token
representing the dialog in association with the control channel.

<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 SIP ‘Dialog-token’ MUST now be
inserted into every control framework command that specifically applies to the
SIP dialog that generated the token.  On receiving a control framework command
with a valid ‘Dialog-token‘, the processing on the resource can
take place with knowledge that the command has legitimately been generated by a
trusted source.  A control framework command that does not have a valid
token MUST be rejected with a xxx response.  The ‘Dialog-token’
can be passed around to other entities that have control channels set up. 
This mechanism is out of the scope of this document but requires a high level
of security to ensure that unwanted commands can not be issued by rogue entities. 

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>TODO – add mechanism to example - <font
size=2 face=Arial>full
media dialog example would be needed in the IVR package<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'>TODO – BNF for SIP + SCFW headers.

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>TODO – Cover REPORT messages.

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>TODO – How does this relate to Conferencing?
 Maybe use Control-token for conference operations (which can also be
passed around).

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

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

<span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----
From: McGlashan, Scott
[mailto:[email-masked]] 
Sent: 26 July 2006 19:47
To: Chris Boulton;
[email-masked]
Cc: Tim Melanchuk; Asher
Shiratzky; Burger, Eric
Subject: RE: Who said you could do
that!!!!

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

<font size=2 color=blue
face=Arial>Hi
Chris,

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

<font size=2 color=blue
face=Arial>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 size=3
face="Times New Roman"> 

<font size=2 color=blue
face=Arial>Scott  

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

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

<p class=MsoNormal style='margin-right:0cm;margin-bottom:12.0pt;margin-left:
36.0pt'><span style='font-size:10.0pt;font-family:
Tahoma;font-weight:bold'>From:<span
style='font-size:10.0pt;font-family:Tahoma'> Chris Boulton [mailto:[email-masked]]

Sent: Tuesday, July 25, 2006 11:29
To:
[email-masked]
Cc: McGlashan, Scott; Tim
Melanchuk; Asher Shiratzky; Burger, Eric
Subject: Who said you could do
that!!!!

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

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

<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):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<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: <[email-masked]>
Date: Thu, 27 Jul 2006 16:54:49 +0100

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>I wasn’t at the meeting and am sure
I’m not following fully the discussion and thinking on this topic. But
let me ask whether a certain scenario was considered.

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>Suppose you have one or more control
channels set up between an AS and an MS. The application is such that the AS
instructs the MS to initiate an outgoing call leg.

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>For example

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>- dialing out from the MS to add a party
to a conference
- dialing out from the MS to an individual party (e.g. as part of a
mass-calling event “School is closed on account of snow.”)

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>In that kind of situation, where the MS
does the SIP signaling ‘directly’ toward the end party and so there
isn’t the step of the AS sending a call leg to the MS, what token method
works? Especially if you want to move control instructions from one control
channel to another (e.g., the AS had two with the MS in case one fails).

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>Of course, we could make it a rule/assumption
that the AS is always involved in the SIP signaling/establishment of a leg with
an MS and so the above scenario is out of scope, but that would not be my
preference.

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>cheers,

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<font size=2
  color=blue face=Arial><span style='font-size:11.0pt;font-family:Arial;
  color:blue'>Gary<font size=2 color=blue
face=Arial>

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> 

<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>
[email-masked] [mailto:[email-masked]]
On Behalf Of Chris Boulton
Sent: Thursday, July 27, 2006
10:38 AM
To: McGlashan, Scott;
[email-masked]
Cc: Tim Melanchuk; Asher
Shiratzky; Burger, Eric
Subject: [mediactrl] RE: Who said
you could do that!!!!

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

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Scott – this was an attempt to
‘start’ trying to get some words around the proposals – not
really to add a new one.  I have since realized that this wasn’t
very clear and so here is another attempt at an early straw-man – based
on diagram 2 (which is my preferred choice).  If someone has a major
preference for (1) from the minutes then I think we should work on that text as
well.  I have included the diagram as well for some clarity this time <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:

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>One of the primary usages of the SIP Control
Framework is to manipulate associated 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 control channel token
on establishing a control channel which is then included in other related
events such as the creation of a SIP media dialog.  The entity receiving
the SIP INVITE request then includes a unique dialog token in the SIP success
response message.  The two entities involved in the control channel
interaction then both have possession of a ‘Control-token’ and more
importantly a shared ‘Dialog-id- token.  The unique
‘Dialog-id’ token returned is then included in all control
framework commands that specifically operate on such resources.  A driving
example being an IVR command being passed on the control channel directed at a
users media dialog (represented by the ‘Dialog-id’).  The
token returned when establishing the control channel is then included in the
SIP media dialog creation.  The 200 OK then returns the unique dialog-id
token that is included in any control framework messages that operate on the
SIP dialog resources.  A command that arrives on a Control Channel
destined for a media dialog that is not deemed associated with a resource will
not be successful.

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>When generating the Control Framework
‘SYNC’ message (on establishing the control channel [ref]), the
generating client SHOULD include a ‘Control-token’ header which
contains a unique token to identify the control channel being established (TODO
- talk about randomness).  Clients MAY choose not to include a
‘Control-token’ header if they have definitive knowledge that no
other entity is capable of issuing un-solicited Control Framework messages.
 A client receiving a ‘SYNC’ message that does not contain
‘Control-token’ and has policy that insists on using this mechanism
can respond with an xxx error response.

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>When forwarding a dialog request (such as a users
media dialog) to a client with an established control channel that has an
associated ‘Control-token’, a SIP ‘Control-token’
header MUST be included.  If not present and a ‘Control-token’
exists for the association (as determined by control channel set-up), the
request should be rejected (TODO – using what?  New response code
– xxx ‘No Security association’).  If the entity
receiving the request locates the SIP ‘Control-token’ header but
does not have knowledge of the token value, the request MUST also be rejected
(TODO – using the previous response).  If the value contained in the
‘Control-token’ header is valid and the request is a success, the
responding client MUST include a SIP ‘Dialog-token’ header which
contains a token representing the dialog in association with the control
channel.

<span lang=EN-GB style='font-size:
10.0pt;font-family:Arial'>The SIP ‘Dialog-token’ MUST now be
inserted into every control framework command that specifically applies to the
SIP dialog that generated the token.  On receiving a control framework
command with a valid ‘Dialog-token‘, the processing on the resource
can take place with knowledge that the command has legitimately been generated
by a trusted source.  A control framework command that does not have a
valid token MUST be rejected with a xxx response.  The
‘Dialog-token’ can be passed around to other entities that have
control channels set up.  This mechanism is out of the scope of this
document but requires a high level of security to ensure that unwanted commands
can not be issued by rogue entities. 

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span style='font-size:
10.0pt;font-family:Arial;color:navy'>TODO – How does this relate to
Conferencing?  Maybe use Control-token for conference operations (which
can also be passed around).

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span style='font-size:

<span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----
From: McGlashan, Scott
[mailto:[email-masked]] 
Sent: 26 July 2006 19:47
To: Chris Boulton; [email-masked]
Cc: Tim Melanchuk; Asher
Shiratzky; Burger, Eric
Subject: RE: Who said you could do
that!!!!

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

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

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

<span
style='font-size:10.0pt;font-family:Arial;color:blue'>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.

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

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

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

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

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><span style='font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:<font
size=2 face=Tahoma> Chris
Boulton [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 11:29
To:
[email-masked]
Cc: McGlashan, Scott; Tim
Melanchuk; Asher Shiratzky; Burger, Eric
Subject: Who said you could do
that!!!!

<span

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

<span

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

<span

<span

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

<span

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

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

<span

<span

<span

<span

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

<span

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

<span

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

<span

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

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

<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: "Chris Boulton" <[email-masked]>
Date: Mon, 31 Jul 2006 11:17:25 +0100

<span style='font-size:

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

<font size=2 color=blue
face=Arial>Suppose
you have one or more control channels set up between an AS and an MS. The
application is such that the AS instructs the MS to initiate an outgoing call
leg.

<font size=2 color=blue
face=Arial>For
example

<font size=2 color=blue
face=Arial>-
dialing out from the MS to add a party to a conference
- dialing out from the MS to an individual party (e.g. as part of a
mass-calling event “School is closed on account of snow.”)

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

<font size=2 color=blue
face=Arial>In that
kind of situation, where the MS does the SIP signaling ‘directly’
toward the end party and so there isn’t the step of the AS sending a call
leg to the MS, what token method works? Especially if you want to move control
instructions from one control channel to another (e.g., the AS had two with the
MS in case one fails).

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

<font size=2 color=blue
face=Arial>Of
course, we could make it a rule/assumption that the AS is always involved in
the SIP signaling/establishment of a leg with an MS and so the above scenario
is out of scope, but that would not be my preference.

<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 personally had been under the impression
that the controlling entity (AS) would be involved in the signaling establishment. 
If it is not then you open up a whole new world of passing information to the
AS relating to call legs.  I would be interested in other folks opinions on
this one.

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

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

<span style='font-size:

<font size=2 color=blue
face=Arial>cheers,

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

<font size=2 color=blue
  face=Arial>Gary

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

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

<font

<span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:<font
size=2 face=Tahoma>
[email-masked]
[mailto:[email-masked]] <span style='font-weight:
bold'>On Behalf Of Chris Boulton
Sent: Thursday, July
 27, 2006<span style='font-size:10.0pt;
font-family:Tahoma'> <span
 style='font-size:10.0pt;font-family:Tahoma'>10:38 AM<font
size=2 face=Tahoma>
To: McGlashan, Scott;
[email-masked]
Cc: Tim Melanchuk; Asher
Shiratzky; Burger, Eric
Subject: [mediactrl] RE: Who said
you could do that!!!!

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

<font size=2 color=navy
face=Arial>Hi Scott
– this was an attempt to ‘start’ trying to get some words
around the proposals – not really to add a new one.  I have since
realized that this wasn’t very clear and so here is another attempt at an
early straw-man – based on diagram 2 (which is my preferred
choice).  If someone has a major preference for (1) from the minutes then
I think we should work on that text as well.  I have included the diagram
as well for some clarity this time <font size=2 color=navy
face=Wingdings>J<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>.

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

<font size=2
face="Courier New">UAC                  
AS1                  
MS                   
AS2

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                  
  |                    
|

<font size=2
face="Courier New"> |                    
|Establish Control
Channel                 
|

<font size=2
face="Courier New"> |                    
|-------------------->|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|token1              
|                    
|

<font size=2
face="Courier New"> |                    
|<--------------------|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |
                    |                    
|                    
|

<font size=2
face="Courier New"> |INVITE
sip:[email-masked]         
|                    
|

<font size=2
face="Courier New"> |-------------------->|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|     
               |

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|INVITE w/ token1    
|                    
|

<font size=2
face="Courier New"> |                    
|-------------------->|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|200 OK (w/ dialog-token)                  
|

<font size=2
face="Courier New"> |                    
|<--------------------|  
                  |

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |200
OK              
|                    
|                    
|

<font size=2
face="Courier New"> |<--------------------|    
                |                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |ACK                 
|                    
|                    
|

<font size=2
face="Courier New"> |-------------------->|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|ACK                 
|           
         |

<font size=2
face="Courier New"> |                    
|-------------------->|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|(application dialog,
|                    
|

<font size=2
face="Courier New"> |                    
| w/ dialog-token)   
|                    
|

<font size=2
face="Courier New"> |                    
|.....................|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |               
     |                    
|                    
|

<font size=2
face="Courier New"> |                    
|Magic token exchange
|                    
|

<font size=2
face="Courier New"> |                    

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|(application dialog, |

<font size=2
face="Courier New"> |                    
|                    
| w/ dialog-token)    |

<font size=2
face="Courier New"> |                    
|                    
|.....................|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|                    
|

<font size=2
face="Courier New"> |                    
|                    
|  
                  |

<font size=2
face="Courier New"> |                    
|                    
|                    
|

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

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

<font size=2 color=navy
face=Arial>Here is
a starter, another very rough straw-man:-

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

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

<span
lang=EN-GB style='font-size:10.0pt;font-family:Arial'>One of the primary usages
of the SIP Control Framework is to manipulate associated 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 control channel token on establishing a control channel which is then
included in other related events such as the creation of a SIP media
dialog.  The entity receiving the SIP INVITE request then includes a
unique dialog token in the SIP success response message.  The two entities
involved in the control channel interaction then both have possession of a
‘Control-token’ and more importantly a shared ‘Dialog-id-
token.  The unique ‘Dialog-id’ token returned is then included
in all control framework commands that specifically operate on such
resources.  A driving example being an IVR command being passed on the
control channel directed at a users media dialog (represented by the
‘Dialog-id’).  The token returned when establishing the
control channel is then included in the SIP media dialog creation.  The
200 OK then returns the unique dialog-id token that is included in any control
framework messages that operate on the SIP dialog resources.  A command
that arrives on a Control Channel destined for a media dialog that is not
deemed associated with a resource will not be successful.

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

<span
lang=EN-GB style='font-size:10.0pt;font-family:Arial'>When generating the
Control Framework ‘SYNC’ message (on establishing the control
channel [ref]), the generating client SHOULD include a ‘Control-token’
header which contains a unique token to identify the control channel being
established (TODO - talk about randomness).  Clients MAY choose not to
include a ‘Control-token’ header if they have definitive knowledge
that no other entity is capable of issuing un-solicited Control Framework
messages.  A client receiving a ‘SYNC’ message that does not
contain ‘Control-token’ and has policy that insists on using this
mechanism can respond with an xxx error response.

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

<span
lang=EN-GB style='font-size:10.0pt;font-family:Arial'>When forwarding a dialog
request (such as a users media dialog) to a client with an established control
channel that has an associated ‘Control-token’, a SIP
‘Control-token’ header MUST be included.  If not present and a
‘Control-token’ exists for the association (as determined by
control channel set-up), the request should be rejected (TODO – using
what?  New response code – xxx ‘No Security
association’).  If the entity receiving the request locates the SIP
‘Control-token’ header but does not have knowledge of the token
value, the request MUST also be rejected (TODO – using the previous
response).  If the value contained in the ‘Control-token’
header is valid and the request is a success, the responding client MUST
include a SIP ‘Dialog-token’ header which contains a token
representing the dialog in association with the control channel.

<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 SIP
‘Dialog-token’ MUST now be inserted into every control framework
command that specifically applies to the SIP dialog that generated the
token.  On receiving a control framework command with a valid
‘Dialog-token‘, the processing on the resource can take place with
knowledge that the command has legitimately been generated by a trusted
source.  A control framework command that does not have a valid token MUST
be rejected with a xxx response.  The ‘Dialog-token’ can be
passed around to other entities that have control channels set up.  This
mechanism is out of the scope of this document but requires a high level of
security to ensure that unwanted commands can not be issued by rogue entities. 

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

<font size=2 color=navy
face=Arial>TODO
– add mechanism to example - <span
lang=EN-GB style='font-size:10.0pt;font-family:Arial'>full media dialog example
would be needed in the IVR package<font size=2 color=navy
face=Arial>.

<font size=2 color=navy
face=Arial>TODO
– BNF for SIP + SCFW headers.

<font size=2 color=navy
face=Arial>TODO
– Cover REPORT messages.

<font size=2 color=navy
face=Arial>TODO
– How does this relate to Conferencing?  Maybe use Control-token for
conference operations (which can also be passed around).

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

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

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

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

<span
Sent: 26 July 2006<font
size=2 face=Tahoma> 19:47<font
size=2 face=Tahoma>

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

<font size=2 color=blue
face=Arial>Hi
Chris,

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

<font size=2 color=blue
face=Arial>Could

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

<font size=2 color=blue
face=Arial>Scott  

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

<font

<p class=MsoNormal style='margin-right:0cm;margin-bottom:12.0pt;margin-left:
72.0pt'><span style='font-size:10.0pt;font-family:
Tahoma;font-weight:bold'>From:<span
style='font-size:10.0pt;font-family:Tahoma'> Chris Boulton
[mailto:[email-masked]] 
Sent: Tuesday, July
 25, 2006<span style='font-size:10.0pt;
font-family:Tahoma'> <span
 style='font-size:10.0pt;font-family:Tahoma'>11:29<font size=2
face=Tahoma>
To:
[email-masked]
Cc: McGlashan, Scott; Tim
Melanchuk; Asher Shiratzky; Burger, Eric
Subject: Who said you could do
that!!!!

<span

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

<span

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

<span

<span

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

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

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

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

<span

<span

<span

<span

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

<span

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

<span

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

<span

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

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

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

<span