Re: [MEDIACTRL] MRB discussion list for Thursday

["MUNSON, GARY A, ATTLABS" <[e-mail]>]

Hi all,

Some feedback from me. As usual, I won't be attending the meeting.
I only provided feedback [GAM] where I have some kind of opinion.

cheers,

Gary

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Lorenzo Miniero
Sent: Monday, March 22, 2010 5:28 PM
To: [e-mail]
Subject: [MEDIACTRL] MRB discussion list for Thursday

Dear all,

to anticipate the discussion we'll have on the MRB next Thursday, I
list in here all the relevant points that will be raised during the
meeting. The post addresses both the posts Eric sent to the list
recently, and the RAI expert review made by Ben.

I tried to summarize each issue, together with the related
proposed solution or discussion: let us know what you think about them.
A link to where each issue has been reported/discussed is provided as
well, where applicable. If you think there is any other relevant point
we're missing, tell us and we'll add it to the bunch.

All the results from the discussion will end up in the updated version
of the MRB document that Chris and I plan to make available ASAP after
the meeting.




1) DTMF support -- INFO

http://www.ietf.org/mail-archive/web/mediactrl/current/msg01531.html

INFO is currently listed in the supported formats that may be reported
in both the Publishing and Consumer interfaces. Nevertheless, it
has been pointed out that actually there's currently no standard at all
for carrying DTMF in INFO messages: the existing solutions
are proprietary, and as a consequence there's probably no
interoperability at all. Besides, as far as we know no MS supports them
anyway.

    Solution: The idea is to completely remove support for it. Would you
miss it, is there any reason it should be kept in?

[GAM] Fine with removing.

2) Extensibility of the schemas

http://www.ietf.org/mail-archive/web/mediactrl/current/msg01532.html

The schemas are currently not extensible for some fields. It is the
case, for instance, of 'msstatus', 'action', 'actions', 'dtmf' and
'vxml', which have a fixed enumeration list for the possible values
(check the attached post for a detailed review of the fields and their
values). Extensibility is good, but having it also raises other
potential issues, as the need for a proper related signaling to have
the involved parts be aware of what is known and what isn't.

    Solution: Two possible solutions, (i) either we stick to the
fixed fields and decide on a reasonable set for them, (ii) or we allow
extensibility deciding how to handle it (do we add signaling for
extensions, or the MRB barfes/ignores whenever it meets something
unexpected?



3) Call legs management

This comes from some thoughts deriving from our early implementation
experience with the MRB, and has also been mentioned in a few older
posts. It is related to how the MRB is supposed to handle call legs in
case it is on the signalling path as well, which may happen in some
cases. This should not ben an issue for both Query and IAMM, since in
both cases the AS placing the Consumer request ends up with the URI of
the MS that has been assigned to it: this means that the AS can simply
redirect calls there, as envisaged in the Framework. Nevertheless, the
MRB may *want* to be in the signalling path for any reason. It may be a
problem for IUMM instead: in fact, in IUMM the AS is not aware of any
MRB, and talks to it as if it were the MS itself. This means that the
MRB would *always* be in the signaling path, and so, if the AS has more
CFW channels with the MRB, associated with >1 MS, there may be a problem
in redirecting call legs to the right MS associated with its business
logic.

    Solution: (i) For what concerns the MRB wanting to be in the
signaling path also for Query and IAMM, a solution would be to allow
the MRB to dynamically allocate local URIs associated with the
actual MS the AS has been assigned. This would allow the MRB to stay in
the signaling path for all call legs as well, giving it more control (to
more effectively enforce leasing, for instance). This probably is just
an implementation/deployment choice, and so does not need an explicit
specification text in the doc, but mentioning it as a guideline might be
useful; what do you think of this?
             (ii) For what concerns the IUMM issue, it's a bit more
tricky... in fact, whatever we decide to do, it must be something that
unaware AS and MS must support. Always relaying CFW sessions
from the same MRB-unaware AS to the same MS (just as the MRB were in
fact a single MS instance) would solve it, but would also introduce
obvious scalability concerns. It has been proposed to use a
conference-id token for such a feature, but I'm not completely
convinced by this, considering an application logic session in the MS
is something that goes beyond the concept of a conference (the same
call might be attached to several different things during its lifetime,
IVR dialogs, other call legs, a mixer and so on); besides, such id would
need to be supported by the MS as well. Nevertheless, some kind of
token like that might solve the problem... Any suggeston?

[GAM] I have never been a fan of IUMM and would be happiest if it were
removed altogether. If kept, I would be fine as simply citing this
problem as another limitation on IUMM's scope of
usefulness/applicability.


The following points are instead related to Ben's RAI expert review:

http://www.ietf.org/mail-archive/web/mediactrl/current/msg01533.html




4) "The publish interface defines yet another way to do subscriptions.
Since it's based on mediactrl, this means using a SIP dialog to
establish a mediactrl session for these subcriptions. The data in this
case feels like metadata related to signaling more than content.  Did
the working group consider the possibility of using SIP-events? (RFC
3265)? If so, what was the motivation for creating something new?
(Perhaps other mediactrl packages already have subscription semantics,
and this follows their precedents? It's been a long time since I read
the IVR package)"

    Solution: The best solution to address both Publishing and Consumer
interfaces has been the subject of long discussions. At the end we
agreed (in San Francisco, if I recall correctly) that re-using the
native functionality the CFW provides would be the best choice, since
(i) all MS would support it anyway, and (ii) such a native notification
mechanism comes for free. Besides, the package-based nature of the CFW
makes it very easily extensible for new features. The choice was
discussed again after San Francisco as well (an HTTP vs CFW debate) but
the proposed approach was confirmed.

[GAM] I still support use of CFW.


5) "You note that the consumer inline interface can be equivalent to
the query interface when the MRB sends a 3XX response. Why, then, do
you propose two ways to accomplish the same thing? It seems like this
just makes life harder for everyone. Implementations will have to
implement both methods in order to be interoperable with any other
arbitrary implementation."

    Solution: At first the IAMM only envisaged the multipart/mixed
approach: the 3xx option was added to address some comments from the
list. The interoperability issue already applied to the higher level
different approach between the Query and Inline topologies. Our
proposal would be to keep the alternatives we have in the draft,
since they give more freedom to implementers to decide what's best
for them. What is your opinion about this? Should we add some more text
to address the issues, in that case?

[GAM] My preference would be to remove 3XX.


6) "The inline approach to the consumer interface basically involves
the MRB acting as a b2bua to select downstream destinations according
to the app server preferences. This is very similar to the problem
caller-prefs [RFC 3841] set out to solve. Did the work group consider
using caller-prefs  as the basis?"

    Solution: This may be something worth investigating, as long as it
doesn't means a complete rewrite. I'm not familiar with the
caller-prefs RFC, and so need to give it a good read before
understanding what we can re-use. Any suggestion on what we could take
advantage of from that spec?

[GAM] I don't think we should change anything. The way I see it, if you
start with Query Mode, where the MRB is the endpoint that the AS is
talking to over http, it makes sense to have the AS attributes as
payload rather than http headers in that case. But then we are simply
re-using the same scheme for IAMM - the AS doesn't have to populate the
attributes any differently, just supply it as payload in SIP. A good
case of re-use. Yes, we could have done something more like 3841,
involving SIP headers, and that would involve perhaps re-use to some
degree, but I don't see it as ultimately a better approach.

7) "You need some more "big picture" discussion about the lease
mechanism. Does "lease" imply the MRB is managing resources--i.e.
keeping state of allocated resources against available resources, etc,
rather than simply depending on the MS to provide the information? If
so, can the MS and the MRB get out of sync? Is it legal to have some
access to a given MS be direct, and other via the MRB? If there are
multiple MRBs do they need to share resource state?"

    Solution: This isn't the first comment we received on the leasing
mechanism (there are other on the ML), so I guess we definitely need
some more details related to the how it is assumed to work. Some more
control may be enfored by means of the discussion of 3), but that's
just an idea. Any suggestion/preference?

[GAM] Would suggest making the points that
 a) The model where MRB manages the MS resources (as stated above - i.e.
keeping state of allocated resources against available resources, etc,
rather than simply depending on the MS to provide the information) is
indeed on envisioned model. But it is not a requirement.
 b) In the case of that model, it is understood that MRB knowledge of MS
resources is imperfect (that is actually already written in the spec, if
I recall) and MRB and the MSes could get out of sync. Remedies to that
may involve, e.g., MRB receiving MRB updates over Publish or receiving
information over an operations interface on MS status (out of scope
here).
 c) Logically, we're viewing MRB as a single entity. Nature of a
distributed MRB and how those pieces would communicate is out of scope.
 d) Nothing precludes implementations where multiple MRBs utilize the
same MS server, or an AS directly utilizes an MS that may also be
utilized through an MS. There's no rule here that says you can't shoot
yourself in the leg. I.e., stuff like that compromises the value of
using an MRB, or at least increases complexity in overall operation in
ways that we don't intend to address here.

8) "Are 409 and 410 the only allowed errors? Why a separate error codes
that only seem to differ as to the request type? Also, from experience
in defining MSRP, I think it is a mistake to choose error codes for
other protocols to match those of SIP or HTTP. This causes a lot of
confusion in place the meanings are subtly different. It also causes
layer confusion (When someone says they got a 409, is that a SIP 409,
or an mrb-consumer 409?)"

    Solution: You're right, the document currently is a bit "poor"
on the error management. We'll definitely add more error codes in the
next version. So far we chose to focus on the relevant features first,
and then address errors, which is what should done now. I agree about
keeping the error codes set separated from well-known ones, and we'll
take that into account. Are you all ok with this?


9) "What are the uniqueness requirements (scope, chance of collision,
etc) for "id"? (Question applies to all the ID attributes in this
draft.)"

    Solution: That's a good point, and it has been discussed internally
as well. The idea we came out to would be to limit the scope of
uniqueness to "unique within the scope of media servers controlled by a
MRB". Do you think this is enough? Or do you have any other concern
related to that?

[GAM] I think that scope of uniqueness you suggest suffices.

10) "I think seqnumber needs some more explanation. How is it
constructed? Can the recipient infer anything about gaps in sequence
numbers? Do  you have to worry about roll over? Do you have separate
sequence spaces in each direction (like CSeq for SIP?)"

    Solution: seqnumber has the same role it has in the framework
drafts, and in fact it has been added as a consequence of the
experience we already had with the previous specifications. We'll
clarify its role in the next version of the document.



11) "I'm not sure I understand what a non-active session is. Do you
mean available ports, resources, etc that could be used for sessions?
Is that the right way to express available resources? (For example, how
would you express available CPU cycles in terms of available sessions?)
I think you mentioned this issue somewhere, but I'm not sure I agree
that you've found the right abstraction here."

    Solution: I guess you mean both mixer and RTP sessions, since they
both have an 'active' and 'non-active' counterpart. After a long
discussion in previous meetings, such an approach was decided to be the
most effective (less harmful?) one. Rather than RTP sessions, this has
to be intended as encoding/decoding sessions, since both mixer and RTP
sessions in the document are associated with a reference codec. Such
codecs, together with the number of sessions, should allow for a
calculation of the expected/effective CPU utilization. We'll add more
text to the document to make this clearer. Is there any other concern
related to that which we should address as well?

[GAM] One comment that might be helpful here is to once again
acknowledge that what MS provides MRB over Publish is understood to
impart pretty good but likely knowledge of MS resource
utilization/availability. One of the things that MRB may employ is a
capacity model for any particular MS or type of MS which it may use to
derive a more accurate view of MS resource utilization based on the
input over Publish. But the nature of such a capacity model and how MRB
is provided it is out of scope.

12) "What's the practical difference between deactivated and
unavailable?"

    Solution: From a practical point of view, probably nothing. In
both cases, a MS can't be reached. But it may be useful to keep them
both, e.g. for statistic reasons or something like that. Our proposal
would be to keep them both, is anyone opposed to it?

[GAM] Yes, would prefer keeping both.

13) "What kind of name goes in the supported format. Is this a MIME
type, or some other managed namespace? (Similar questions apply for the
values for other "name" attributes in the draft, where the name spaces
or registries need to be defined.)"

    Solution: The same comment applies to other elements in the
schema. We'll clarify the constraints for all of them. Is there any
other element specification we should clarify accordingly?



14) "It's worth discussing the fact that the IAMM model involves a
b2bua modifying SIP bodies. This impacts the ability to use any SIP
security feature that protects the body (e.g. 4474, s/mime, etc.)
unless the MRB intermediates the security association. Given that one
of points of using SIP for mediactrl in the first place was to reuse
SIP features when possible, I think this is an issue."

    Solution: A very good point, we'll address this in the security
considerations: this may apply to only the CFW channel negotiation, if
the MRB is not in the signaling path for call legs as well, but it's
still an issue. Any other related concern that we should add to the
security considerations accordingly?



15) "The security considerations talk about channel security, but not
so much about authorization. I think it's important to make sure only
authorized application servers can get information about media servers,
etc."

    Solution: Good catch, it probably may a good idea to also add an
authorization mechanism as well, in order to make sure that only
authorized AS can make use of the MRB. Any suggestion?

[GAM] Sounds good. I don't think we need anything exotic, and it should
be optional.


That's all, see you on Thursday!

Thanks,
Lorenzo

-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com/
_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl