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:27:18 +0100

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: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 2 Jun 2006 18:35:32 +0100

<FONT face=Arial 
color=#0000ff size=2>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
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Cheers,
<FONT face=Arial 
color=#0000ff size=2> 
<FONT face=Arial 
color=#0000ff size=2>Martin

From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Burger, 
EricSent: Friday, June 02, 2006 1:31 PMTo: Garland 
Sharratt; [email-masked]: 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 
[<A rel="nofollow" 
href="mailto:[email-masked]">mailto:[email-masked]]Sent:   
Wednesday, May 17, 2006 06:39 PM Eastern Standard 
TimeTo:     
[email-masked]:        
RE: [mediactrl] a few comments on AS-MS-related topics; and the Control 
Framework for SIP draft - MRBOf course I believe that SIP media servers 
are better (easier to use, moreflexible, etc.) than H.248 or MGCP media 
servers.  That's not being debatedhere.  Some vendors (mostly 
NEPs) will tend toward H.248, while (IMO) mostvendors (mostly app vendors) 
will tend toward SIP.  I don't think this islikely to change in the 
near term, although I hope SIP wins out in the longterm.The key 
thing is that a media server is a media server: a device whosepurpose 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.248media 
server does: play, record, mix, DTMF, etc.But the real issue in all this 
protocol debate, in my view, is that there isa discontinuity between what in 
the market and what's in the IMSarchitecture.  The market has mostly 
SIP media servers and some H.248 mediaservers.  IMS has an H.248 media 
server (it's the MRFP) but *not* a SIPmedia server: the MRF is a superset of 
a SIP media server, loaded withfunctions that don't fit a pure media 
server.  The MRF is the closest thing to a SIP media 
server.  But if SIP mediaservers 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 explicitMRB as it was assumed that, since the media 
servers are the MRFPs, the MRBfunction 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][<A rel="nofollow" 
href="mailto:[email-masked]">mailto:[email-masked]] 
On Behalf Of Burger,EricSent: Tuesday, May 16, 2006 09:33To: Garland 
SharrattCc: [email-masked]: RE: [mediactrl] 
a few comments on AS-MS-related topics; and theControl Framework for SIP 
draftI would offer that there can be nothing further apart than the 
model,and thus application space, offered by H.248 (device control) 
andSIP+XML (where the XML is not just encapsulated MGCP).I will very 
quickly concede that you can do anything in H.248.  It justtakes more 
protocol messages, much more complex applications, andsophisticated 
controllers.Saying a media server "just does media processing" totally 
misses thepoint.  If that were the case, I would offer that SMIL has 
been around alot longer and has many more implementations.  Why don't 
we useHTTP/SMIL for media servers?  It is because the programming 
anddeployment model is entirely different from what people want to 
usemedia servers for.-----Original Message-----From: 
[email-masked][<A rel="nofollow" 
href="mailto:[email-masked]">mailto:[email-masked]] 
On Behalf Of GarlandSharrattSent: Wednesday, May 10, 2006 9:42 AMTo: 
'Tom-PT Taylor'; Gary Munson [AT&T]Cc: 
[email-masked]: RE: [mediactrl] a few comments 
on AS-MS-related topics; and theControl Framework for SIP draftTom, 
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 youlookat an H.248 media server and a SIP 
media server, there is no realdifferencebetween them.  Both do the 
same job, media processing.  Yes, the controlinterface looks different, 
but they are both doing playing, recording,DTMFcollection, conference 
mixing, etc.  Yes, pure VoiceXML (pure = no callcontrol, e.g., 
"transfer" element) is often used with SIP media serversandnot with 
H.248 media servers, but this doesn't change the role orfunctionof a 
media server, which is to perform media processing under the totalcontrol of 
an external application.2. Inline MRB vs. Query MRBI don't 
really have an axe to grind on either side but based on what Iknowat 
this time I don't agree that the Query MRB is better than the 
InlineMRB.The Query MRB needs new protocols and interfaces defined, 
whereas theInlineMRB 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 tohave visibility of BYE messages (which is necessary for 
resource controlpurposes) it needs to also flow through all the SIP INFO 
messages, whichisinefficient.)The last time I looked at the MSF 
has only the Inline MRB, not the QueryMRB.  Tom, has this really 
changed?3. Separate TCP control channel negotiated by SIPI 
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,onevery viable way to use these channels would be to have *one* 
suchlong-liveTCP channel set up between each combination of AS and MS, 
at restarttime.The AS would use the one TCP channel to control all its 
RTP streams onthatMS. So if there were N ASs and M MSs, there would be N 
x M controlchannels,assuming all ASs had access to all MSs.  
Perhaps there could also be atime-out mechanism that might tear down a TCP 
channel if it hadn't beenusedin an hour, if this was valuable for some 
reason.  And of course if aparticular MS isn't useable by a particular 
AS, there would be no TCPchannel.I don't see a conflict between 
having these long-lived TCP channels andthepresence of the 
MRB.Comments welcome.Garland-----Original 
Message-----From: [email-masked][<A rel="nofollow" 
href="mailto:[email-masked]">mailto:[email-masked]] 
On Behalf Of Tom-PTTaylorSent: Wednesday, February 15, 2006 08:24To: 
[email-masked]: [email-masked]: Re: 
[mediactrl] a few comments on AS-MS-related topics; and theControl Framework 
for SIP draftThe MSF has taken the Media Resource Broker into its 
architecture, withtwo different SIP interfaces. The first requests media 
resources of aspecific type, with a URI to a media server as a return 
result. Thesecond has the MRB acting as a proxy (optional) between the 
client andthe 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 thisarchitecture were to persist but with the SIP setting 
up separatecontrol channels, I find it hard to picture those channels 
remaining uponce the individual call is completed. Control channels 
persisting forlonger than the duration of an individual usage (call) imply a 
tighterrelationship between the AS and the MS than I think compatible with 
therole of a media resource [email-masked] wrote:> 
Hi folks,>> I'll throw in my views here on some topics that have 
been in therecentemails, say from February 4 onward.>> 1) 
It seems that there are two basic concepts of what is meant 
byMediaServer>     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 befundamentally addressing is (b); 
but it should be extensible to allowfinercontrol granularity. In a 
practical architecture, it should be possibleforthe 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 everyitsy-bitsystep. So, yes, 
something like VXML on the MS makes perfectly good sense.Onthe other 
hand, to preclude a potentially finer level of control 
forsomeapplications seems unwise. >> 2) While I used 
above the representation of the 'smarter' MS as IMSMRFC+MRFP, as have 
others, it has a flaw. The IMS MRFC consists of twofunctions. One is the 
MRFP control function, which is okay to be part oftheMS. But the MRFC 
also has a media resource *assignment* function. At thenetwork level, that 
assignment function cannot be part of a MediaServer.(Local resource 
assignment among a cluster of servers is a differentmatter.) [One other side 
note - in an earlier mail, the AS-MS controlinterface was referred to, in 
IMS terms, as the Mr interface. On the MSsidethat's fine.  However, 
in the IMS pictures I have seen, the Mr interfacehasas its other 
endpoint the S-CSCF, not the AS.]>> * That MS assignment function 
is related to topics that came inmultipleearlier emails about MS 
discovery, and whether we're assuming a staticconnection between an AS and 
MS, and whether the resource managementfunction lives 'below 
S-CSCF'.> One of the scenarios we need to allow for is a many-to-many 
AS-MSrelationship where the MS resources are a shared pool across 
manydifferentservices residing on many ASes, with tons of traffic with 
variations involumes, some predictable, some not, and where MS resources are 
notinfiniteand the MS boxes don't all have the same size or capability 
set, andservices don't all have the same priority, etc.. In such as case, 
wewant to> - Allow for a network-level MS assignment function 
(referred to as aMediaServer Resource Broker or just Media Resource 
Broker); one model of thewayMSRB works (e.g., recent work in the 
ATIS-PTSC and in the ITU-T NGNbased ona set of requirements), is for an 
AS to query the MSRB when it wants MSresources. The MSRB responds to the AS 
with identified MS resources thatitallocates to that AS.  When the 
AS is done with its assigned MSresources,it releases them back to the 
MSRB. In that model, the MSRB doesn't havetolive below, and can be 
unrelated to, S-CSCF. There is another model ofMRBthat would live below 
S-CSCF, but it doesn't support as broad a set ofneedsas 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 MSresource management/allocation as important, they 
should remain outsidethescope of the BoF AS-MS protocol effort, and we 
should allow the AS-MScontrol channel connection situation to be 
fluid.>> Next, a couple comments for Chris & co on the "A 
Control Framework forSIP" draft, staying out of the Control Package fray, 
and questions aboutwhich protocol might be a chicken or an egg  
:-)     -->> A) I resonate strongly with the 
option of having a separate AS-MScontrolchannel set up by SIP, and TCP 
for transport is good. Here are someadditional points to potentially 
clarify:>   a) *Must* the control channel be established before 
a call leg isbrought to the Media Server? The Control Framework for SIP 
draft seemstoonly talk about setting up the control channel before a 
call leg isbroughtto the MS. It might be useful to allow for 
both.>   b) Can a single control channel be used to control 
multiple calls attheMS (using the same control package)? For example, 10 
simultaneous IVRsessions?  I believe the intent is to allow that, but I 
didn't see wordstothat effect.>  c) Can different control 
packages be run over the same controlchannel?For example, one for 
simultaneous calls for IVR and another forconferences?I don't have a 
strong feeling about that one, but it should beclarified.>> B) 
The 'Control Framework for SIP' draft places the ControlPackage-related 
information at the SIP-level (the Control Packagesheaderetc.) in SIP 
messages. An alternative would be to place that informationinan SDP or 
SDP-like description as payload, similar to establishing mediasessions using 
SIP. I wonder whether there was any discussion around thepros and cons of 
doing the latter?  [I do realize media channels andcontrolchannels 
are not the same thing]. Take this question as one that is 
amildpush-back, and perhaps based on ignorance as much as 
anything.>> Cheers,>> Gary 
Munson>>>>> 
--------------------------> Ubiquity Software does not control or endorse 
the content, messages orinformation found in this mail list and it 
specifically disclaims anyliability with regard to these 
communications.> Ubiquity Software reserves the right the restrict access 
to anycommunications in violation of the Terms and Conditions of Use for 
thiswebsite or as otherwise deemed 
improper.>>--------------------------Ubiquity Software 
does not control or endorse the content, messages orinformation found in 
this mail list and it specifically disclaims anyliability with regard to 
these communications.Ubiquity Software reserves the right the restrict 
access to anycommunications in violation of the Terms and Conditions of Use 
for thiswebsite or as otherwise deemed 
improper.--------------------------Ubiquity Software does not 
control or endorse the content, messages orinformation found in this mail 
list and it specifically disclaims anyliability with regard to these 
communications.Ubiquity Software reserves the right the restrict access to 
anycommunications in violation of the Terms and Conditions of Use for 
thiswebsite or as otherwise deemed 
improper.--------------------------Ubiquity Software does not 
control or endorse the content, messages orinformation found in this mail 
list and it specifically disclaims anyliability with regard to these 
communications.Ubiquity Software reserves the right the restrict access to 
anycommunications in violation of the Terms and Conditions of Use for 
thiswebsite 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.