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

From: "Burger, Eric" <[email-masked]>
Date: Fri, 2 Jun 2006 18:45:26 +0100

Here is another place where the 3GPP model is broken. The distinction isn't "if it touches RTP it must be service control." The distinction is, "if it touches access, it is the access network, if it offers applications, it is part of the applications/services network." See the IMS Forum reference architecture for a picture.

--
Sent from my Palm Treo - Sorry if Terse

 -----Original Message-----
From:   Dolly, Martin C, ALABS [mailto:[email-masked]]
Sent:   Friday, June 02, 2006 01:38 PM Eastern Standard Time
To:     Burger, Eric; Garland Sharratt; [email-masked]
Subject:        RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB

The Media Server Resource Function (Broker) is already supported in the ATIS-PTSC-SAC NGN(IMS) arch. and in the ITU NGN arch as well. With liaisons to TISPAN and 3GPP. We (AT&T) prefer the function in the Application layer, but allow for it to be supported in the service control layer

Cheers,

Martin

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Burger, Eric
Sent: Friday, June 02, 2006 1:31 PM
To: Garland Sharratt; [email-masked]
Subject: RE: [mediactrl] a few comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB

I was speaking with a partner, and they had what I thought was a good idea.

It is clear that when providers actually build networks, they will be keen to reduce useless complexity. The question will be, "Do I really need 17 distinct boxes?" The answer will invariably be "No." An obvious place for consolidation will be the MRF.

By the same token, there are obvious componets that will get deployed that are not one of the 17 IMS boxes. An example of this is a web load balancer. If one has a farm of web servers behind the AS, most networks will put a standard load balancer in between. There is no IMS "box" for that, but it is getting done that way.

Could we just say the best practices for deploying MRF might include a load balancer? *We* know that load balancer is what we've been calling a MRFB. However, would we have to advertise it that way?

--
Sent from my Palm Treo - Sorry if Terse

 -----Original Message-----
From:   Garland Sharratt [mailto:[email-masked]]
Sent:   Wednesday, May 17, 2006 06:39 PM Eastern Standard Time
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.

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.

--------------------------
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: <[email-masked]>
Date: Fri, 2 Jun 2006 19:07:55 +0100

Framework for SIP draft - MRB

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>I’m not uncomfortable with saying
that best practices for MRB/MRFB/MRBF (whatever letters we’re using) deployment
might include a load balancer, as an option, depending on needs.

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

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>It would be bad, however, to equate the
terms load balancer and MRB. MRB may be doing more than load balancing in any
ordinary sense. It may, for example, be ensuring that traffic of flavor A doesn’t
prevent traffic of flavor B from getting its fair share of MS resources. It may
be looking for a best fit for a really large conference that has to straddle MS
boxes. It may be looking for MS conference resources preferentially on the West
Coast because the AS says that’s where most of the participants will be
for a particular conference.

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

<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]] <span style='font-weight:
bold'>On Behalf Of Burger, Eric
Sent: Friday, June 02, 2006 1:31
PM
To: Garland Sharratt;
[email-masked]
Subject: RE: [mediactrl] a few
comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB

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

I was
speaking with a partner, and they had what I thought was a good idea.

It is clear that when providers actually build networks, they will be keen to
reduce useless complexity. The question will be, "Do I really need 17
distinct boxes?" The answer will invariably be "No." An obvious
place for consolidation will be the MRF.

By the same token, there are obvious componets that will get deployed that are
not one of the 17 IMS boxes. An example of this is a web load balancer. If one
has a farm of web servers behind the AS, most networks will put a standard load
balancer in between. There is no IMS "box" for that, but it is
getting done that way.

Could we just say the best practices for deploying MRF might include a load
balancer? *We* know that load balancer is what we've been calling a MRFB.
However, would we have to advertise it that way?

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

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

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

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

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

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

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

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.

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. 

Comments welcome.

Garland

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

recent
Media
Server
MRFC
multiple
Media
SIP" draft, staying out of the Control Package fray, and questions about
which protocol might be a chicken or an egg  :-)    
--
control
the
channel?

--------------------------
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: "Chris Boulton" <[email-masked]>
Date: Tue, 6 Jun 2006 09:13:35 +0100

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

<font size=2 color=blue
face=Arial>I’m
not uncomfortable with saying that best practices for MRB/MRFB/MRBF (whatever
letters we’re using) deployment might include a load balancer, as an
option, depending on needs.

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

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

<font size=2 color=blue
face=Arial>It would
be bad, however, to equate the terms load balancer and MRB.

<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 Boulton] yes.

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

<font size=2 color=blue
face=Arial> MRB
may be doing more than load balancing in any ordinary sense.

<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 Boulton] Most certainly.

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

<font size=2 color=blue
face=Arial> It
may, for example, be ensuring that traffic of flavor A doesn’t prevent
traffic of flavor B from getting its fair share of MS resources. It may be
looking for a best fit for a really large conference that has to straddle MS
boxes. It may be looking for MS conference resources preferentially on the West
Coast because the AS says that’s where most of the participants will be
for a particular conference.

<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] This raises the main question that confuses
me the most.  Where exactly do we draw the line between standardizing a
simple load/routing mechanism that can take factors such as capability sets
into account and an extremely complex beast that is able to
monitor/allocate/retrieve resources + route accordingly.  To me the latter
is way to complex for this group to contemplate in first phase - so where is
the line drawn (I guess this is important if we were putting together our
charter)?

<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:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'> 

<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=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]] <span style='font-weight:
bold'>On Behalf Of Burger, Eric
Sent: Friday, June
 02, 2006<span style='font-size:10.0pt;
font-family:Tahoma'> <span
 style='font-size:10.0pt;font-family:Tahoma'>1:31 PM<font size=2
face=Tahoma>
To: Garland Sharratt;
[email-masked]
Subject: RE: [mediactrl] a few
comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB

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

<span
style='font-size:10.0pt'>I was speaking with a partner, and they had what I
thought was a good idea.

 -----Original Message-----
Sent:   Wednesday,
 May 17, 2006 06:39
PM Eastern Standard Time

-----Original Message-----
Sent: Tuesday, May
 16, 2006 09:33<span
style='font-size:10.0pt'>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Garland<font
size=2>
Sharratt
Sent: Wednesday, May
 10, 2006 9:42 AM<span
style='font-size:10.0pt'>
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<font
size=2>, a few belated comments on your two
emails together:

Comments welcome.

Garland<font
size=2>

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

recent
Media
Server
MRFC
multiple
Media
control
the
channel?

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: Tue, 6 Jun 2006 22:34:45 +0100

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

<span style='font-size:

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>Regarding your last inserted comment below
“This raises the main question that confuses me most. Where exactly do we
draw the line …” - 

<span style='font-size:

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>I’m thinking that there are several
approaches to the resource location/MRB function that are acceptable and should
be described. For the sake of illustration, the story outline might be 
 ‘Inline’ methods

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>  a) info implicit in the SIP URI
content itself and proxy routing on that 

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>  b) making use of additional info
that can come in a SIP INVITE at the level of netann (RFC 4240)

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>  c) making use of additional info such
as user agent capabilities and caller preferences (RFCs 3840, 3841)

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>  ‘Query’ method
   a) separate query to MRB, say using http and payload in XML format

<span style='font-size:

<span style='font-size:
11.0pt;font-family:Arial;color:blue'>A service provider/network provider would
implement whatever suffices for their service needs. Certainly not simple, but
I personally don’t view the Query method as an ‘extremely complex
beast’. On the network side/call handling side, it gets a request from an
App Server, looks at data and cranks through an algorithm and returns a result.
On the operations side, it gets per-service reservation info, and MS status
info that may include downtime/out of service status and periodic MS snapshots.
But I’m not trying to trivialize all that, either.

<span style='font-size:

<span style='font-size:
11.0pt;font-family:Arial;color:blue'> It would be interesting to hear what
other folks have to say about the MRB/resource location topic in general.

<span style='font-size:

<span style='font-size:

<span style='font-size:

<font size=2

<span style='font-size:

<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> Chris Boulton
[mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 4:16
AM
To: Munson,Gary A (<st1:City
w:st="on">Gary);
[email-masked]; [email-masked]
Subject: RE: [mediactrl] a few
comments on AS-MS-related topics; and the Control Framework for SIP draft - MRB

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

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

<span
style='font-size:11.0pt;font-family:Arial;color:blue'>I’m not
uncomfortable with saying that best practices for MRB/MRFB/MRBF (whatever
letters we’re using) deployment might include a load balancer, as an
option, depending on needs.

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

<span

<span style='font-size:

<span
style='font-size:11.0pt;font-family:Arial;color:blue'>It would be bad, however,
to equate the terms load balancer and MRB.

<span

<span

<span

<span
style='font-size:11.0pt;font-family:Arial;color:blue'> MRB may be doing
more than load balancing in any ordinary sense.

<span

<span

<span

<span
style='font-size:11.0pt;font-family:Arial;color:blue'> It may, for
example, be ensuring that traffic of flavor A doesn’t prevent traffic of
flavor B from getting its fair share of MS resources. It may be looking for a
best fit for a really large conference that has to straddle MS boxes. It may be
looking for MS conference resources preferentially on the West Coast because the
AS says that’s where most of the participants will be for a particular
conference.

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

<span
charter)?<span
style='font-size:10.0pt;font-family:Arial;color:blue;font-weight:bold;
font-style:italic'>

<span

<span

<span

<span

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

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

<st1:place
 w:st="on"><span style='font-size:11.0pt;
  font-family:Arial;color:blue'>Gary

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

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

<span

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

<span

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

Tom, Gary, a

Comments welcome.

Garland

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

recent
Media
Server
MRFC
multiple
Media
control
the
channel?

<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