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

From: <[email-masked]>
Date: Tue, 23 May 2006 18:37:36 +0100

<font size=2
  face=Tahoma>Garland
and folks,

Regarding
the topic below of MRB and MRFC/MRFP/IMS and “Does anyone see a solution
to this?” question, the way I look at it is:

1)
The Media Server (your SIP MS, I guess) is ‘an’ MRF, i.e., MRFC +
MRFP. That MS can still have a localized resource assignment function, e.g.
among a cluster of servers. But it doesn’t include the network-level MRB.

2)
The MRB function should be acknowledged as a separate network function. How it
works and where it fits into a network architecture can vary depending on what
needs have to be met. (and could be an Inline MRB or a Query MRB of some kind).
That whole story needs to be developed.

3)
IMS is defined to serve a certain set of needs. There are things one could add
to an overall NGN architecture, or clarify about an overall NGN architecture,
whether or not they officially become part of IMS. Related to this exploder’s
scope, MRB as a separate function is one. An AS – MS (or AS – MRF) direct
control channel is another.

Cheers,

<font size=2
  face=Tahoma>Gary

-----Original
Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Garland Sharratt
Sent: Wednesday, May 17, 2006 6:38 PM
To: [email-masked]
Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the
Control Framework for SIP draft - MRB

Of
course I believe that SIP media servers are better (easier to use, more

flexible,
etc.) than H.248 or MGCP media servers.  That's not being debated

here. 
Some vendors (mostly NEPs) will tend toward H.248, while (IMO) most

vendors
(mostly app vendors) will tend toward SIP.  I don't think this is

likely
to change in the near term, although I hope SIP wins out in the long

term.

The
key thing is that a media server is a media server: a device whose

purpose
is to do media processing on media streams.  Whether it's SIP, MGCP,

H.248,
SMIL, or RS-232, it's still a media server.  Is the SIP one better?

Yes,
of course, but it's still doing the same kinds of things that an H.248

media
server does: play, record, mix, DTMF, etc.

But
the real issue in all this protocol debate, in my view, is that there is

a
discontinuity between what in the market and what's in the IMS

architecture. 
The market has mostly SIP media servers and some H.248 media

servers. 
IMS has an H.248 media server (it's the MRFP) but *not* a SIP

media
server: the MRF is a superset of a SIP media server, loaded with

functions
that don't fit a pure media server.   

The
MRF is the closest thing to a SIP media server.  But if SIP media

servers
become MRFs to fit into IMS, where is the media resource broker

(MRB)
function done?  Large service providers are asking for a separate

(physical)
MRB component in their networks.  IMS doesn't have an explicit

MRB
as it was assumed that, since the media servers are the MRFPs, the MRB

function
would be done in the MRFC.  But if the media server is the MRF,

there
is no separate MRFC to do the MRB role.  

Does
anyone see a solution to this?

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

From:
[email-masked]

[mailto:[email-masked]]
On Behalf Of Burger,

Eric

Sent:
Tuesday, May 16, 2006 09:33

To:
Garland Sharratt

Cc:
[email-masked]

Subject:
RE: [mediactrl] a few comments on AS-MS-related topics; and the

Control
Framework for SIP draft

I
would offer that there can be nothing further apart than the model,

and
thus application space, offered by H.248 (device control) and

SIP+XML
(where the XML is not just encapsulated MGCP).

I
will very quickly concede that you can do anything in H.248.  It just

takes
more protocol messages, much more complex applications, and

sophisticated
controllers.

Saying
a media server "just does media processing" totally misses the

point. 
If that were the case, I would offer that SMIL has been around a

lot
longer and has many more implementations.  Why don't we use

HTTP/SMIL
for media servers?  It is because the programming and

deployment
model is entirely different from what people want to use

media
servers for.

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

From:
[email-masked]

[mailto:[email-masked]]
On Behalf Of Garland

Sharratt

Sent:
Wednesday, May 10, 2006 9:42 AM

To:
'Tom-PT Taylor'; Gary Munson [AT&T]

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.

<font size=2
  face=Tahoma>Garland

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

From:
[email-masked]

[mailto:[email-masked]]
On Behalf Of Tom-PT

<font size=2
  face=Tahoma>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.

--------------------------

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.