(
http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-01)
Now that we're looking more seriously at this draft, we're getting
better feedback...
Lorenzo has raised an issue with the 423 response and clarification on
the transaction ID in the draft.
This is the first version of the draft to include a Security
Considerations section - please review this section carefully.
Dan York talked about issues around multiple Media Servers and security
concerns around interaction with multiple channels (especially
involving hijack and misuse). Dan will send specific concerns to the
list.
Lorenzo supports removal of the separate event mechanism but is
concerned that we may have problems with MS starvation - do we need to
add some kind of keepalive mechanism?
There are a number of references to "Transaction-Time" in the draft,
but we don't have a suggested value for this. Scott suggested 10
seconds as a starting point, and then begged for working group inputs,
which seemed to tend toward 5 seconds. Keith pointed out that the
choice of a value depends on the action you expect to take when the
timeout expires.
Simon pointed out that in the draft, the transaction timeout has the
right definition at beginning, but later there is a recursive
definition.
Spencer made snarky comments about the interaction between really long
TCP retry behavior and much shorter application-level timers - in HTTP,
we also have (user-supplied) timeouts, when the user gives up and hits
"reload", so that's fine, we just need to be clear that
application-level timeouts will require a TCP connection close and
reopen to "clear the pipe".
We had a similar conversation around "Upper-Limit" for recommended
value to be included in the 'Timeout' header of a REPORT message - the
strawman suggestion was 15 seconds.
(
http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-06.txt)
Roni has been raising issues on the mailing list on a concern involving
the interaction of the IVR package and SIP SDP-less INVITEs (when the
AS gets to 200 OK without knowing the purpose of the INVITE).
Spencer asked the working group to carefully review Roni's concerns -
as Lorenzo pointed out, there has been a long discussion on the mailing
list, but it hasn't converged yet. Spencer also asked Scott and Roni to
discuss in more detail, while we're in the same time zone.
We're considering adding iterations/duration to <basicivr> - if
we do (and it looks like we will), can we remove this from
<prompt>? If there's a use case that requires it, please say so
very soon.
Dan York asked if music on hold would be an example of use case where
iteration of prompt and dialog would be different.
The sense of the room supports the chairs adopting the next version of
this draft as a working group item (this doesn't actually require
working group consensus).
(
http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-04.txt)
Support for Real-Time Text is still an open issue for this package.
Mary Barnes asked for quick input to XCON because XCON is close to
completing their data model - if we need it, it's important that it
appears in the XCON data model.
The authors would like to be pointing to XCON templates - Alan Johnston
asked the authors to bring this topic to XCON, very soon.
Simon pointed out that the document should also mention interaction
with the conference control package and conference control protocol.
With the exception of Real-Time Text, there aren't many remaining
issues for this draft. The sense of the room supports the chairs
adopting the next version of
this draft as a working group item (again, this doesn't actually
require
working group consensus).
(
http://tools.ietf.org/wg/mediactrl/draft-miniero-mediactrl-escs-01.txt)
Simon was presenting the -01 version of the draft (which wasn't
completed until after the Internet Draft cutoff - it was submitted
during the IETF meeting).
We discussed having a separate VCR XML control element as part of IVR,
and decided to ignore this possibility for now...
This turned into a very detailed discussion comparing what the package
authors think the specifications say, to what the call flow authors
think they say.
Scott understood the need for clarification on several points.
Is there a specific order for <prompt>, <collect>,
<record>? If so, please say so soon.
The chairs are really glad we have this feedback loop... please keep
implementation experience coming.
- IETF 72 work plan (Chairs)
In reviewing the charter milestones, we're not doing too badly. The
biggest source of movement is the insertion of the MEDIACTRL Control
Framework - we rely on it for the packages, but it's not a MEDIACTRL
milestone.
There's a knock-on schedule effect - we've made a lot of progress on
the packages, but the packages will have a normative dependency on the
MEDIACTRL Control Framework, so we can't actually FINISH the packages
until we FINISH the Control Framework.
The chairs will discuss with Jon-the-AD, but the way it's looking after
IETF 71 is:
- Framework document to IESG – Revise to be March 2008 vs Nov 2007
current milestone
- Mediactrl Control Framework WGLC – May 2008 (need RAI expert
review first)
- IVR Control Package – June 2008
- Mixer Control Package – Sept WGLC (we'll rename this milestone as
"Conference Control", since that's the document name)
- Broker Protocol WGLC – no change
Spencer is still somewhat nervous about making these dates - in his
opinion, we must do one of the following to make these dates:
- Nail down the common audit capabilities for the Mediactrl Control
Framework really quickly, or
- Drop common audit capabilities from the Mediactrl Control
Framework (it's the last big open issue), or
- Schedule an interim meeting.
Of these choices, the first two are preferable.