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

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

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:[e-mail]] 
Sent: Thursday, January 14, 2010 5:54 AM
To: Henry Lum
Cc: [e-mail]
Subject: Re: [MEDIACTRL] Questions for draft-ietf-mediactrl-mrb-02

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

Chris.


Henry Lum wrote:
>
> 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.
>
[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.

[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 
> 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?
>
[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.

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

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

[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 
> 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?
>
[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.

[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.

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

[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?

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

[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?

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