– Discussion Leader is Chris Boulton
The current document is:
draft-ietf-mediactrl-sip-control-framework-03.txt
Draft went through WGLC and we've gotten an RAI review from Ben Campbell (good comments, thank you, Ben, and the comments have been addressed by document editors)
Chairs begged that any remaining open issues be sent to the mailing list ASAP.
Main open issue is Security Section; need security expert – action
item for chairs
New version to be prepared directly after Dublin meeting. We will need to run new text past the working group before publication.
- Discussion Leader is Scott McGlashan
Current version is the -00 control package -
draft-mediactrl-ivr-control-package-00.txt
RAI expert review from Ben Campbell
Editor has been making changes in response to
comments, editor's notes, and fixing nits. Thinks the next version will
be ready for WGLC.
IVR – 200 : request from Author for help in ASCII
Art - Scott will provide PowerPoint pictures to Mary Barnes, who
has graciously offered to convert to ASCII art.
IVR 201 : author proposal accepted
IVR 202: remove ‘ndn’ ; MSCML had ndn,
inherited from PacketCable; agreed to remove
IVR 203: XCON defines Codec type, but no
other data supplied; any data needed; author recommends a
<params> field; agreed
RAI comments: Security needs beyond RFC
3023; proposal: add link to security section of framework
document; other security issues?
Response: Need to add meat into the section
and add everything into text; Specifically, what are the security
considerations for this document above and beyond the framework - can't
just defer to the framework document - need to clearly state that
security is channel-based, and we don't think there are multiple
channels with different security permissions.
ASR Out of Scope – Ben questioned why ASR is out
of scope; Should this be added to milestones
View of chairs: VoiceXML covers 80% of
Speech apps; get Media Control framework and 2 basic packages done;
beyond that other uses could be considered in a re-chartered work group.
Do we have to do ASR now? Chairs prefer to get
framework and two basic packages already underway finished before
looking at other packages.
Sense of the
room: No request from the room to address ASR now - maybe later.
4.2.1 “src” attribute: What URI schemes make sense
here? Ben: What sort of URI would make sense, even if it is not
specified; Decision: Need text on what sort of URI would make sense
(even if not specific) ; need an error code for unsupported URI scheme.
The audit response doesn't include supported URI
schemes, but no discovery is needed because you can just retry with a
different scheme
(if another scheme makes sense - if no other scheme makes sense then
trying the only reasonable scheme is equivalent to discovery anyway).
4.2.5.2 dtmf and timestamp attributes
If multiple characters, what does timestamp
mean? Answer: Last DTMF digit (completion of tone detection when
it matched); agreed
4.3.1 behavior for prompt and record at same time
is not defined; change how this is described so that it is clearer;
this behavior will be described as “MAY”
Mixer 001 – should we define
<conferenceexit> notification that conference exited (for
example, no participants attached yet). Sense of the room:
agreed (an
<unjoin-notify> would not work, so this is required).
Mixer-002 – Video Layouts - allow participants not
providing a video input steam to conference to be displayed on layout
(e.g avatar case); support or leave for advanced mixer package;
decision: out of scope (no one in the room was excited about this).
Lorenzo asked about providing different reviews of
the same conference to different participants - this will be deferred
to an advanced video package "later".
Mixer – 003 video layout – need ASCII pictures of
the layouts – Mary volunteered to help
Mixer – 004 conference audit – we have ID, codecs
and participants, do we need more conferencing information? -
Yes, current active layout
Mixer – 005 participants – Is this the right
term? What to call connection endpoints - sense of the room is
that "participants" is OK
Chair: STRONGLY ncourages that WG
participants offer comments on WG documents prior to the end of WGLC
("there is no penalty for getting WGLC comments in EARLY ...")
– Discussion Leader is Lorenzo Miniero
Lorenzo's implementation includes an AS (SIP Servlet) and MS. This implementation is up-to-date on all drafts except VXML.
Scott has an implementation of Framework, IVR and
Mixer packages, and Scott has also been feeding issues back into the
specifications (where Scott is an editor).
Framework-related comments:
IVR-releated comments:
Mixer-related comments:
Lorenzo's team has prepared a call flows draft as
part of their implementation work - currently it's an invididual
contribution
Should it be a WG item? Chair: suggests it be an
individual contribution
Mary: Call flow documents are important; she’d think it should be
normative; concern from chair about contradictions between normative
docs and call flows
Comments from floor: If the draft is important, make it a WG item
Keith: 3GPP would not look for flows from IETF, but rather
normative documents
Scott: 3GPP would at least use this document as a
starting point for their work.
Chair: Should the call flow document be added to the
charter?
Roni: The packages documents need to have priority over the call
flows
Martin: I find the document valuable, as a tool to explain the output
of this working group to eventual implementers.
Keith: What would the reason be to add: if there is a need for
the document and the WG will work on it?
Chair: Hum on objecting to adding it to the charter? Nobody
objected
Chair: Who in the WG will review the call flows
document? Several hands were raised.
Roni: Concern that the call flows need to be correct and often
will vary from the specs
Steve Norris pointed out that both BT and ATT will
do call flows documents internally, and will either start with our
document or "something else", with likely interop consequences.
Christer: Call flows are good for talking with customers, but no
substitute for the normative document. If contradiction, go
back to normative document.
Keith: is the goal to produce for sample call flows or implementation
agreements for interop (torture tests)?
Names of call flow reviewers: Chris, Scott, Martin, Mary, Janet
Gunn, and several others
Chairs are very concerned about schedule slips,
and would like discussion about an interim meeting.
Do we also need an interop event?
Co-located?
Date constraints: We don't have formal
requirements for advance notification for an Interop but we really need
30 day notice. For an interim, requirement is 30 days notice and 30
days +/- IETF. That gives this possible range of dates: 1 September -
17 October.
It would be lovely to do both events at the same
time, but the participants are likely to be different between interop
and interim, anyway.
Cullen is expecting a flock of RAI interims in
January (after IETF 73).
Christer – 3GPP CT1 meeting in North America, in
October; potential to get participation - joint workshop?
Fold interop into normal SIPit? Second week of
October, in Brittany.
HP Implementation – Framework, IVR and Mixer
packages; also VoiceXML support
Many issues discovered and fed back into
specification.
Would like to start doing interop – looks like 4
implementations so far that could participate in an interop event.
Christer pointed out that additional implementers are waiting for 3GPP
work to finish on MRF (which will mandate support for these packages).
Dan York comment: why not do at SIPit?
- discussion leaser is Chris Boulton
Status:
doc parked to after initial work group items started
Recap:
Different architectural models: 1:M, M:M, etc.
Don't have a consensus architectural model (yet).
Differing interface options: SNMP, SOAP,
subscribe/notify, REST, etc.
Draft will provide a tool kit to allow following
deployment models
Next steps:
Want to spend next period continuing to collect
requirements for publishing and consuming interfaces.
Should this version be the basis for WG milestone?
Proposal: defer decision to IETF-73
Discussion:
Roni: need to consider XCON protocol
The chairs strongly encouraged the working group
to consider deadlines that are less than one-IETF-cycle chunks!
Any changes to milestones?
No objections to the changes as above presented by the chairs, although Mary (wisely) pointed out that the milestones are aggressive.