Subject: [MEDIACTRL] Questions for draft-ietf-mediactrl-mrb-02

From: "Henry Lum" <[email-masked]>
Date: Wed, 13 Jan 2010 14:21:07 -0800

Hi Chris, Lorenzo,

I have a bunch of questions for the MRB draft (02).

-          Section 1 - While it is clear that an MRB is used for
selecting a media server based on capability sets, it is unclear to me
whether an MRB can be used to selecting media server based on capacity
for 1:M and M:M deployments. This is mentioned in section 3 as well as a
way to request for available resources.

-          Section 3 - When MRB function is not required in a deployment
because there is only one media server in the deployment, then how does
AS that is MRB-aware cope with deployments where MRB function does not
exist?

-          Section 4.1 - For the query type MRB, do we expect the
consumer client to find the MRB using HTTP interface only? 

o   If SIP is used, do we expect the SIP dialog to be a persistent
dialog? If so, what is the lifetime of this dialog?

o   How do the application server and media server address the MRB? Is
this an implementation issue for AS/MS to find a well-known address of
such component? 

o   If the MRB is unavailable, what should the AS/MS do? Should they
treat it as an error and retry later or abandon it and continue regular
processing as if MRB does not exist in the deployment?

-          Section 4.2 - How does the consumer interface disappears for
IAMM? Isn't the AS still embed the consumer tags as part of the INVITE
message?

-          Section 5.1 - If the media control framework defines the
ability to provide auditing of packages, why do we need to define the
publisher interface anyways? Can't the MRB just connect to all the media
servers that it knows and use <audit> to figure out all the capabilities
embedded by each of the packages. Using the SYNC message, the controller
client can negotiate all the packages the media server supports, and can
then use audit to figure out all the capabilities and codecs supported
by the media server. I understand that MRB will need to audit every
single package provided by each media server, but then the publisher
interface looks to me like a normalization of the ivr and mixer packages
and the MRB ends up having to understand the union of both capabilities
anyways.

-          Section 5.2.2 - The multi-part requirement seems to be a bit
too strict (MUST) when it requires that the multi-part content to be
specifically ordered as the first and second part. Also, it does not
address the case where the INVITE contains no offer.

o   Can the <mediaResourceResponse> be carried in a SIP reliable
response for media server that supports early media?

-          Section 5.2.3 - It mentions a lease mechanism here, but the
concept seems incomplete here. I don't see any mention of what a lease
mean in this context? Does the lifetime of a session directly relate to
the lifetime of a lease? Does the AS need to lease a resource before
using it for every single call for IAMM? I see that the response format
kind of implies this is the case in section 5.2.5.1.1 as the expires
value need to be refreshed periodically. Do we expect the AS to maintain
a lease for every single call as a separate lease (IAMM) or do we expect
the AS to know the full capacity of all the resources it will ever need
and maintain just one lease (Query)?

-          Can MRB refuse to provide a lease if there is not enough
capacity? If so, which response code is that?

-          Let's say an MRB manages multiple brands of conference
servers and there is an overlap of capabilities of the conference
servers. If the consumer client can only describe the capability
required in the INVITE, then is it the responsibility of the AS or the
MRB to maintain the affinity to the same conference server for all
future participants? I can understand that for the query method the
response can provide an URI of the conference server and the AS will
explicitly choose this URI for routing the participants to the
conference.

Thanks

Henry

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Chris Boulton <[email-masked]>
Date: Thu, 14 Jan 2010 10:53:44 +0000

Hi Henry - thanks for the comments. Responses in-line.

Chris.

Henry Lum wrote:
> - Section 1 – While it is clear that an MRB is used for selecting a 
> media server based on capability sets, it is unclear to me whether an 
> MRB can be used to selecting media server based on capacity for 1:M 
> and M:M deployments. This is mentioned in section 3 as well as a way 
> to request for available resources.
>
[Chris] The actual selection detail and algorithms for media server 
selection are out of the scope of this document. The intention is to 
provide all the information necessary to make those decisions.
>
> - Section 3 – When MRB function is not required in a deployment 
> because there is only one media server in the deployment, then how 
> does AS that is MRB-aware cope with deployments where MRB function 
> does not exist?
>
[Chris] AS today are generally configured to use MS statically today. 
Its really down to your implementation how you handle the move towards 
an MRB driven architecture and the cases where its not needed - for 
example, still having the option to configure MS resources directly 
alongside an MRB.
>
> - Section 4.1 – For the query type MRB, do we expect the consumer 
> client to find the MRB using HTTP interface only?
>
> treat it as an error and retry later or abandon it and continue 
> regular processing as if MRB does not exist in the deployment?
>
[Chris] OK - what is clear from comments received so far is that its not 
clear IF/HOW SIP fits into the Query model. It was the initial intention 
that Query mode was simply using HTTP. It looks like we need some extra 
text in the document to talk about the possibility of using Query Mode 
with SIP 3xx responses.

> - Section 4.2 – How does the consumer interface disappears for IAMM? 
> Isn’t the AS still embed the consumer tags as part of the INVITE message?
>
[Chris] The MRB can either act as a B2BUA and remove the information OR 
as a proxy IF it wants to just pass on the info.
>
> - Section 5.1 - If the media control framework defines the ability to 
> provide auditing of packages, why do we need to define the publisher 
> interface anyways? Can’t the MRB just connect to all the media servers 
> that it knows and use <audit> to figure out all the capabilities 
> embedded by each of the packages. Using the SYNC message, the 
> controller client can negotiate all the packages the media server 
> supports, and can then use audit to figure out all the capabilities 
> and codecs supported by the media server. I understand that MRB will 
> need to audit every single package provided by each media server, but 
> then the publisher interface looks to me like a normalization of the 
> ivr and mixer packages and the MRB ends up having to understand the 
> union of both capabilities anyways.
>
[Chris] The publish interface provides resource information that is near 
real-time. This enables the MRB to select appropriate and accurate Media 
Server resources. A lot of the capabilities covered in the MRB publish 
interface are beyond what is covered in the Mixer and IVR audit.
>
> - Section 5.2.2 – The multi-part requirement seems to be a bit too 
> strict (MUST) when it requires that the multi-part content to be 
[Chris] Good point - we need to add appropriate text to cover this use 
case. I took advice from similar IETF documents on the ordering and will 
speak to someone with more knowledge in this area.
>
> - Section 5.2.3 – It mentions a lease mechanism here, but the concept 
> seems incomplete here. I don’t see any mention of what a lease mean in 
> this context? Does the lifetime of a session directly relate to the 
> lifetime of a lease?
>
[Chris] The lease mechanism is independent of the signalling.
>
> Does the AS need to lease a resource before using it for every single 
> call for IAMM?
>
[Chris] Just for that application context. For example, leasing 10 IVR 
ports for Application A. Application A would be safe in the knowledge it 
can use Media Resource B without failure. All we are doing is ensuring 
Media Server B will handle requests for Application A.
>
> I see that the response format kind of implies this is the case in 
> section 5.2.5.1.1 as the expires value need to be refreshed 
> periodically. Do we expect the AS to maintain a lease for every single 
> call as a separate lease (IAMM) or do we expect the AS to know the 
> full capacity of all the resources it will ever need and maintain just 
> one lease (Query)?
>
[Chris] The latter.
>
> - Can MRB refuse to provide a lease if there is not enough capacity? 
> If so, which response code is that?
>
[Chris] Sure - we need to add a response code for that - and generally 
improve all response codes if you have got any suggestions.
>
> - Let’s say an MRB manages multiple brands of conference servers and 
> there is an overlap of capabilities of the conference servers. If the 
> consumer client can only describe the capability required in the 
> INVITE, then is it the responsibility of the AS or the MRB to maintain 
> the affinity to the same conference server for all future 
> participants? I can understand that for the query method the response 
> can provide an URI of the conference server and the AS will explicitly 
> choose this URI for routing the participants to the conference.
>
[Chris] Agreed.
> Henry
1

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 21 Jan 2010 08:39:56 -0800

Hi Chris,

Sorry for the late reply! I was away for a few days.

Please see my comments inline marked [HL].

Thanks!
Henry

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, January 14, 2010 5:54 AM
To: Henry Lum
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Questions for draft-ietf-mediactrl-mrb-02

Chris.

Henry Lum wrote:
> - Section 1 - While it is clear that an MRB is used for selecting a 

[HL] Right, in order to move towards an MRB architecture the AS will
need to eventually need to be MRB-aware. Would it be a good idea to make
a note in this spec to mention that from migration perspective it is
recommended to deploy both IUMM and another mode at the same time so
that all AS, regardless of whether it's MRB aware or not, can take
advantage of MRB?

>
> - Section 4.1 - For the query type MRB, do we expect the consumer 

> - Section 4.2 - How does the consumer interface disappears for IAMM? 
> Isn't the AS still embed the consumer tags as part of the INVITE
message?

[HL] Shouldn't MRB consume the information regardless whether it's B2BUA
or proxy? 

> interface anyways? Can't the MRB just connect to all the media servers

[HL] I can sort of agree with the resource availability part where this
information is not part of audit, but the capabilities exposed is pretty
much the same as audit. I don't see the need to update capabilities
frequently with a subscription model.

>
> - Section 5.2.2 - The multi-part requirement seems to be a bit too 

>
> - Section 5.2.3 - It mentions a lease mechanism here, but the concept 
> seems incomplete here. I don't see any mention of what a lease mean in

[HL] Just to clarify, is leasing optional for AS? In other words,
leasing gives the application the ability to guarantee resources, but
the AS can also choose not to lease by run the risk of requesting for a
resource on demand but refused.

[Chris] The latter.

[HL] If you maintain a lease then in a way the query method becomes a
persistent connection (for SIP) so it's not really a query anymore :)
[HL] A follow up question to this is when a lease is obtained from a
separate query, then how does the AS send the actual request that is
tied to this lease? The only that relates to the lease is the
<session-id>, shall AS reuse this identifier in some way (in signaling)
to attach to this lease?

>
> - Let's say an MRB manages multiple brands of conference servers and 

[Chris] Agreed.

[HL] How should AS operate in IAMM/IUMM for conference affinity? Is it
okay for AS to attach some sort of conference ID (as defined in NETANN)
in signaling so that MRB can remember the affinity? If so, can this be
standardized in this spec?