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

From: Eric Burger <[email-masked]>
Date: Tue, 5 Sep 2006 02:48:00 +0100

We have to make sure that the token is secured on the wire.  Otherwise, an
eavesdropper can take over the sessions, which would be A Bad Thing(tm).

At a minimum, I would suggest wording such as "the control channel MUST use
TLS with encryption to protect the token from eavesdropping."

If we are paranoid, we can use the token, passed over a secure channel, to
be a shared secret for a new, per channel Security Association between the
client and media server.  Personally, I think that is a bit over the top.

On 7/27/06 10:37 AM, "Chris Boulton" <[email-masked]> wrote:

> 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 J.
>  
> UAC                  AS1                  MS                   AS2
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |Establish Control Channel                 |
>  |                    |-------------------->|                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |token1              |                    |
>  |                    |<--------------------|                    |
>  |                    |                    |                    |
>  |                     |                    |                    |
>  |INVITE sip:[email-masked]         |                    |
>  |-------------------->|                    |                    |
>  |                    |                    |                     |
>  |                    |                    |                    |
>  |                    |INVITE w/ token1    |                    |
>  |                    |-------------------->|                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |200 OK (w/ dialog-token)                  |
>  |                    |<--------------------|                     |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |200 OK              |                    |                    |
>  |<--------------------|                    |                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |ACK                 |                    |                    |
>  |-------------------->|                    |                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |ACK                 |                     |
>  |                    |-------------------->|                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |(application dialog, |                    |
>  |                    | w/ dialog-token)   |                    |
>  |                    |.....................|                    |
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |Magic token exchange |                    |
>  |                    |...........................................|
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |                    |(application dialog, |
>  |                    |                    | w/ dialog-token)    |
>  |                    |                    |.....................|
>  |                    |                    |                    |
>  |                    |                    |                    |
>  |                    |                    |                     |
>  |                    |                    |                    |
>  
>  
> Here is a starter, another very rough straw-man:-
> 
>  
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> TODO  add mechanism to example - full media dialog example would be needed in
> the IVR package.
> TODO  BNF for SIP + SCFW headers.
> TODO  Cover REPORT messages.
> TODO  How does this relate to Conferencing?  Maybe use Control-token for
> conference operations (which can also be passed around).
>  
> 
>  
>  
>  
> -----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!!!!
>  
> Hi Chris,
>  
> 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.
>  
> Scott  
>  
> 
> 
> From: 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!!!!
> Hi All,
>  
> 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):
>  
> --------------------------------------------------------------
> 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.
>  
> 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.
>  
>  
> (TODO  update example at the end to include new mechanism  full media dialog
> example would be needed in the IVR package).
> (TODO  include new error response for Control Command that does not contain a
> valid token). 
> (TODO  talk about REPORT  any impact?).
> (TODO  BNF for SIP + SCFW).
>  
> --------------------------------------------------------------
>  
> All input and suggested text welcome,
>  
> 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
> 

--------------------------
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: Eric Burger <[email-masked]>
Date: Tue, 5 Sep 2006 02:48:01 +0100

In simple terms, the media server never, ever, ever, ever, under any
circumstances, establishes a call leg on its own.

How does scenario 1 happen?  The AS issues an INVITE to the conference mix
on the MS with late media.  The MS returns its SDP in the 200 OK.  The AS
issues the INVITE with the SDP of the MS in the offer to the endpoint.  The
AS finishes the SIP handshaking between the MS and endpoint.

How does scenario 2 happen?  The AS issues an INVITE to the endpoint with
late media.  The endpoint returns its SDP in the 200 OK.  The AS issue an
INVITE to the announcement or dialog service on the MS, with the endpoint's
SDP.  The AS finishes the SIP handshaking between the MS and endpoint.

You never, ever, ever, ever want the MS to issue the INVITE because call
progress is usually important to the application; it is unavailable if the
MS issue the invite.  The network may see a call issued, but the media
server has no idea why it issued an INVITE.  Was the INVITE for a conference
($1.00/min)?  Was it for pager notification (free)?  Was it for find-me /
follow-me (variable/min)?  Those are all application-level constructions.
Are you going to provision dial plans on the media server?  What about
per-subscriber dial plans?

All of that goes away when the AS does the signaling.

I hope I'm not too unclear on the concept.

On 7/31/06 6:20 AM, "Chris Boulton" <[email-masked]> wrote:

>  
>  
> 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.
> For example
> - 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.²)
>  
> 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).
>  
> 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.
>  
> [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.
>  
> Chris.
>  
>  
> cheers,
>  
> Gary
>  
>  
> 
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Chris Boulton
> Sent: Thursday, July 27, 2006 10:38 AM
> To: McGlashan, Scott; [email-masked]
> Subject: [mediactrl] RE: Who said you could do that!!!!
>

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 5 Sep 2006 10:31:36 +0100

[Chris Boulton]Agreed.
 
.
.
.
.

You never, ever, ever, ever want the MS to issue the INVITE because call
progress is usually important to the application; it is unavailable if
the
MS issue the invite.

[Chris Boulton] 100% Agreed - and was my point about then needing a
pointless, horrible feedback mechanism. 

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.