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

["Henry Lum" <[e-mail]>]

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.