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

From: <[email-masked]>
Date: Wed, 10 May 2006 19:15:09 +0100

Garland,

Regarding your Comment 2 below, the Query MRB approach addresses a
broader set of needs than the Inline MRB. (Again, conferencing examples,
the AS and not the MRB really knowing when the MS resources can be
released, or the need to control really large conferences that span
multiple MS devices, or the ability to alter a prior request or
negotiate a resource request). I see Query MRB and Inline MRB as
alternatives that one could implement depending on what the particular
needs are. But posing the Inline MRB as the only solution, implying it
meets all needs, is insufficient.

Regarding Comment 3, I agree on both points:
- to allow the TCP connection to be long-lived would be desirable, at
least as an option
- there is no conflict with MRB, whether the Query MRB or Inline MRB
flavor

[Didn't have anything useful to say wrt your Comment 1. Points noted.
:-) ]

Cheers,

Gary

-----Original Message-----
From: Garland Sharratt [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2006 9:42 AM
To: 'Tom-PT Taylor'; Munson,Gary A (Gary)
Cc: [email-masked]
Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the
Control Framework for SIP draft

Tom, Gary, a few belated comments on your two emails together:

1. Dumb media server vs. smart media server.

I don't agree that an H.248 MS is dumb and a SIP MS is smarter.  If you
look
at an H.248 media server and a SIP media server, there is no real
difference
between them.  Both do the same job, media processing.  Yes, the control
interface looks different, but they are both doing playing, recording,
DTMF
collection, conference mixing, etc.  Yes, pure VoiceXML (pure = no call
control, e.g., "transfer" element) is often used with SIP media servers
and
not with H.248 media servers, but this doesn't change the role or
function
of a media server, which is to perform media processing under the total
control of an external application.

2. Inline MRB vs. Query MRB

I don't really have an axe to grind on either side but based on what I
know
at this time I don't agree that the Query MRB is better than the Inline
MRB.
The Query MRB needs new protocols and interfaces defined, whereas the
Inline
MRB doesn't.  For this reason the Inline MRB seems more elegant to me.  

(Incidentally, moving to a TCP channel instead of SIP INFO, see below,
removes one of the objections to the Inline MRB, that in order for it to
have visibility of BYE messages (which is necessary for resource control
purposes) it needs to also flow through all the SIP INFO messages, which
is
inefficient.)

The last time I looked at the MSF has only the Inline MRB, not the Query
MRB.  Tom, has this really changed?

3. Separate TCP control channel negotiated by SIP

I think that for efficiently reasons such a TCP channel needs to be: (a)
long lived, and (b) used to control multiple RTP streams.  For example,
one
very viable way to use these channels would be to have *one* such
long-live
TCP channel set up between each combination of AS and MS, at restart
time.
The AS would use the one TCP channel to control all its RTP streams on
that
MS. So if there were N ASs and M MSs, there would be N x M control
channels,
assuming all ASs had access to all MSs.  Perhaps there could also be a
time-out mechanism that might tear down a TCP channel if it hadn't been
used
in an hour, if this was valuable for some reason.  And of course if a
particular MS isn't useable by a particular AS, there would be no TCP
channel.

I don't see a conflict between having these long-lived TCP channels and
the
presence of the MRB.

Comments welcome.

Garland

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tom-PT
Taylor
Sent: Wednesday, February 15, 2006 08:24
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mediactrl] a few comments on AS-MS-related topics; and the
Control Framework for SIP draft

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

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

--------------------------
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, 10 May 2006 20:40:56 +0100

On comment 3, what bothers me is that since the AS is supposed to 
maintain a semi-permanent connection to each MS, it must presumably know 
the capabilities of that MS. (It obtained the address of the MS through 
the MRB in the first place.) The only reason to get the MRB back into 
the picture is therefore to detect and act on resource exhaustion at a 
particular MS. But if the MS rejects a request from the AS the AS 
already knows what alternatives are available.

[email-masked] wrote:

Garland,

Cheers,

Gary

-----Original Message-----
From: Garland Sharratt [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2006 9:42 AM

Comments welcome.

Garland

-----Original Message-----

[email-masked] wrote:

Hi folks,

recent

Media
Server

MRFC

multiple

Media

control

the

channel?

Cheers,

Gary Munson