[00:35:01] --- eburger has left: Disconnected
[00:46:13] --- eburger has joined
[01:14:15] --- eburger has left: Replaced by new connection
[01:14:15] --- eburger has joined
[01:14:15] --- eburger has left
[01:47:45] --- JACK has joined
[01:53:48] --- eburger has joined
[01:59:35] <eburger> administrivia
[02:02:04] <eburger> Requirements document got lost, but is found now.
[02:02:38] <eburger> Slides are at http://flyingfox.snowshore.com/i-d/speechsc/ under IETF 59
[02:03:07] <eburger> Starting discussion on if we need a separate record function
[02:04:25] <eburger> Sarvi: some recognizers do recording as part of ASR
[02:06:02] <eburger> MRCPv2 has record resource, but is part of recognizer
[02:10:30] <eburger> actually, a generic RECORD resource is available, e.g., for recording voice mail
[02:11:12] <eburger> MRCPv2 (Sarvi)
[02:11:15] <eburger> status
[02:11:49] <eburger> -02 available on web site
[02:12:56] <eburger> changes:
[02:13:01] <eburger> misc edits
[02:13:13] <eburger> Support for SI/SV/Enrollment, etc.
[02:13:37] <eburger> Pending updates
[02:13:54] <eburger> Open Issues
[02:14:00] <eburger> ===========
[02:14:13] <eburger> NAT Traversal issue:
[02:14:48] --- JACK has left
[02:15:37] <eburger> Magnus: is this an issue? If client is in private space, not an issue
[02:16:33] <eburger> Dave: Already using SIP, which means will already have some solution available.
[02:17:34] <eburger> E.g., comedia
[02:19:25] <eburger> We will do whatever SIP uses
[02:19:35] <eburger> Doe we need INTERMEDIAE-RECOG-RESULT?
[02:21:21] <eburger> Chairs: go to mail list. Unless we hear otherwise, will drop from consideration.
[02:21:41] <eburger> Speech or hotword barge-in: do we need any other type?
[02:24:30] <eburger> No objections to having it. Confirm on list
[02:24:50] <eburger> Multiple instances of header fields vs. single header with multiple values
[02:26:56] <eburger> Magnus: probably a mistake (which was Cullen's position), but used by SIP or RTSP
[02:27:46] <eburger> Proposal is to leave as is (both ways)
[02:28:16] <eburger> Issue: Header field ranges: thresholds, etc.: go w/ 0.0 - 1.0 or 0 - 100
[02:29:36] <eburger> Leaning is towards 0.0 - 1.0
[02:30:06] <eburger> Issue: Vendor ID and vendor registry for Recognizer Context Block
[02:31:27] <eburger> Dave: IESG doesn't like idea of vendor extensions that make thigs fail.
[02:31:36] <eburger> Things we need to do:
[02:31:50] <eburger> 1. Having these blocks cannot break protocol
[02:32:27] <eburger> 2. Need to explain why not registering semantics of block
[02:32:41] <eburger> We should ask IANA if there isn't already a vendor name registery
[02:34:04] <eburger> "This introduces no new error cases", and SHOULD/MAY/MUST copy block
[02:34:10] <eburger> Sarvi: MUST copy block
[02:34:53] <eburger> Dave: how about SHOULD: if it cannot copy block, shouldn't fail
[02:35:48] <eburger> Eric: client MUST copy; server MUST NOT barf
[02:37:17] <eburger> Dave: server MUST NOT fail if block is missing
[02:37:26] <eburger> Issue: DTMF and RFC2833 support
[02:37:47] <eburger> DTMF is optional; if DTMF supported, MUST support RFC2833
[02:37:53] <eburger> (already got list consensus)
[02:38:15] <eburger> Issue: Security support: sips, https, digest, SRTP
[02:41:00] <eburger> Eric: looking for minimum baselines for interoperability (what MUST's do we have to have)?
[02:41:16] <eburger> Eric: MUST have TLS for MRCP
[02:41:21] <eburger> Dave: consensus
[02:41:33] <eburger> Sarvi: What about media channel (SRTP)?
[02:42:06] <eburger> Dave: MUST have security of media channel (IPSec or SRTP)
[02:43:59] <eburger> Magnus: can we signal IPSec in SDP?
[02:46:06] <eburger> Eric: prefer IPSec be MUST, SRTP be SHOULD
[02:46:24] <eburger> Dave: Shame to require IPSec since everything else (SIP, MRCPv2) can run over TLS
[02:47:41] <eburger> Should talk to Eric & Jon on security issues
[02:47:55] <eburger> Issue: Define grammars one at a time
[02:47:58] <eburger> consensus
[02:48:32] <eburger> Issue: do we need to have pause on barge-in (instead of kill)?
[02:48:38] <eburger> no - will bring to list
[02:49:06] <eburger> OPTION commands for m-lines
[02:50:57] <eburger> Dave: can't callee capability solve OPTION need?
[02:51:29] <eburger> Take to list
[02:52:52] <eburger> Eric: want to do it as SIP caller caps, so can do routing to resource that has the needed resource
[02:53:39] <eburger> Issue: 3PCC model - how to handle INVITE without offer?
[02:54:30] <eburger> Proposal: server answer includes all m= lines in response (SIP offer)
[02:54:58] <eburger> Dave: Proposal: just use SIP offer/answer RFC326(3?)
[02:56:06] <eburger> Milestones
[02:56:14] <eburger> Target WGLC end of April
[02:56:23] <eburger> (for MRCPv2)
[02:56:45] <eburger> close
[02:56:47] --- eburger has left
[11:18:45] --- eburger has joined
[11:19:19] --- eburger has left