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

[Chris Boulton <[e-mail]>]

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.
>
> - 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.
>
> - 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 
> 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.
>
> 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.
>
> Thanks
>
> Henry
>
>
1