Re: [MEDIACTRL] MRB discussion list for Thursday

REMINDER: THERE IS NO RULE AGAINST STARTING THE DISCUSSION ***NOW***.

On Mar 22, 2010, at 2:27 PM, Lorenzo Miniero wrote:

> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 
> 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.
> 
> 
> 
> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 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?
> 
> 
> 
> 
> That's all, see you on Thursday!
> 
> Thanks,
> Lorenzo
> 
> -- 
> Lorenzo Miniero
> Meetecho s.r.l.
> http://www.meetecho.com/
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl