Subject: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft

From: <[email-masked]>
Date: Wed, 15 Feb 2006 15:41:04 GMT

Hi folks,

I'll throw in my views here on some topics that have been in the recent emails, say from February 4 onward.

1) It seems that there are two basic concepts of what is meant by Media Server
    a) the really dumb kind (a la IMS MRFP)
    b) the one that can be smarter (a la IMS MRFC + MRFP)

  * I believe that the AS-MS protocol that the Mediactrl BoF should be fundamentally addressing is (b); but it should be extensible to allow finer control granularity. In a practical architecture, it should be possible for the AS to tell the MS to do routine tricks on its own (e.g., roll over, fetch a stick, bite the mailman) without the AS controlling every itsy-bitsy step. So, yes, something like VXML on the MS makes perfectly good sense. On the other hand, to preclude a potentially finer level of control for some applications seems unwise.  

2) While I used above the representation of the 'smarter' MS as IMS MRFC +MRFP, as have others, it has a flaw. The IMS MRFC consists of two functions. One is the MRFP control function, which is okay to be part of the MS. But the MRFC also has a media resource *assignment* function. At the network level, that assignment function cannot be part of a Media Server.  (Local resource assignment among a cluster of servers is a different matter.) [One other side note - in an earlier mail, the AS-MS control interface was referred to, in IMS terms, as the Mr interface. On the MS side that's fine.  However, in the IMS pictures I have seen, the Mr interface has as its other endpoint the S-CSCF, not the AS.]

* That MS assignment function is related to topics that came in multiple earlier emails about MS discovery, and whether we're assuming a static connection between an AS and MS, and whether the resource management function lives 'below S-CSCF'. 
One of the scenarios we need to allow for is a many-to-many AS-MS relationship where the MS resources are a shared pool across many different services residing on many ASes, with tons of traffic with variations in volumes, some predictable, some not, and where MS resources are not infinite and the MS boxes don't all have the same size or capability set, and services don't all have the same priority, etc.. In such as case, we want to
- Allow for a network-level MS assignment function (referred to as a Media Server Resource Broker or just Media Resource Broker); one model of the way MSRB works (e.g., recent work in the ATIS-PTSC and in the ITU-T NGN based on a set of requirements), is for an AS to query the MSRB when it wants MS resources. The MSRB responds to the AS with identified MS resources that it allocates to that AS.  When the AS is done with its assigned MS resources, it releases them back to the MSRB. In that model, the MSRB doesn't have to live below, and can be unrelated to, S-CSCF. There is another model of MRB that would live below S-CSCF, but it doesn't support as broad a set of needs as the AS-MSRB model described here. 
- Allow for more than just a static AS-MS control channel situation. 
In short, while recognizing the topics of MS 'discovery' and/or MS resource management/allocation as important, they should remain outside the scope of the BoF AS-MS protocol effort, and we should allow the AS-MS control channel connection situation to be fluid.

Next, a couple comments for Chris & co on the "A Control Framework for SIP" draft, staying out of the Control Package fray, and questions about which protocol might be a chicken or an egg  :-)     --

A) I resonate strongly with the option of having a separate AS-MS control channel set up by SIP, and TCP for transport is good. Here are some additional points to potentially clarify:
  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.
  b) Can a single control channel be used to control multiple calls at the MS (using the same control package)? For example, 10 simultaneous IVR sessions?  I believe the intent is to allow that, but I didn't see words to that effect.
 c) Can different control packages be run over the same control channel? For example, one for simultaneous calls for IVR and another for conferences? I don't have a strong feeling about that one, but it should be clarified.

B) The 'Control Framework for SIP' draft places the Control Package-related information at the SIP-level (the Control Packages header etc.) in SIP messages. An alternative would be to place that information in an SDP or SDP-like description as payload, similar to establishing media sessions using SIP. I wonder whether there was any discussion around the pros and cons of doing the latter?  [I do realize media channels and control channels are not the same thing]. Take this question as one that is a mild push-back, and perhaps based on ignorance as much as anything.

Cheers,

Gary Munson

--------------------------
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: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 15 Feb 2006 16:15:15 GMT

The MSF has taken the Media Resource Broker into its architecture, with 
two different SIP interfaces. The first requests media resources of a 
specific type, with a URI to a media server as a return result. The 
second has the MRB acting as a proxy (optional) between the client and 
the Media Server.

I'll confess that in the short term the MSF is using SIP INFO transport. 
(Strong influence by specific vendors here.) However, if this 
architecture were to persist but with the SIP setting up separate 
control channels, I find it hard to picture those channels remaining up 
once the individual call is completed. Control channels persisting for 
longer than the duration of an individual usage (call) imply a tighter 
relationship between the AS and the MS than I think compatible with the 
role of a media resource broker.

[email-masked] wrote:
Hi folks,