From internet-drafts@ietf.org Sun Oct 30 18:21:02 2011 Return-Path: X-Original-To: speechsc@ietfa.amsl.com Delivered-To: speechsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298421F8C39; Sun, 30 Oct 2011 18:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhCIL+K1CyKg; Sun, 30 Oct 2011 18:21:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2221F8C36; Sun, 30 Oct 2011 18:21:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031012102.5354.16820.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 18:21:02 -0700 Cc: speechsc@ietf.org Subject: [Speechsc] I-D Action: draft-ietf-speechsc-mrcpv2-26.txt X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 01:21:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Speech Services Control Working Group= of the IETF. Title : Media Resource Control Protocol Version 2 (MRCPv2) Author(s) : Daniel C. Burnett Saravanan Shanmugham Filename : draft-ietf-speechsc-mrcpv2-26.txt Pages : 225 Date : 2011-10-30 The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-26.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-26.txt From dburnett@voxeo.com Sun Oct 30 18:25:21 2011 Return-Path: X-Original-To: speechsc@ietfa.amsl.com Delivered-To: speechsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4E11E80AB for ; Sun, 30 Oct 2011 18:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elCu-dg0rw4P for ; Sun, 30 Oct 2011 18:25:20 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7211E80A2 for ; Sun, 30 Oct 2011 18:25:20 -0700 (PDT) Received: from [209.237.253.51] (account dburnett@voxeo.com HELO [10.119.5.202]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 98386213; Mon, 31 Oct 2011 01:20:19 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dan Burnett In-Reply-To: Date: Sun, 30 Oct 2011 21:20:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <313BB3E0-0BC7-464A-BDE9-EE7F5CA24F35@standardstrack.com> To: "Wyss, Felix" X-Mailer: Apple Mail (2.1084) Cc: "speechsc@ietf.org" Subject: Re: [Speechsc] MRCP and mixed IPv4/IPv6 environments X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 01:25:21 -0000 Hi Felix, In our opinion, this problem is unrelated to cmid or MRCPv2 in general. = For example, in SIP the offer may contain multiple media channels, with = a mix of IPv4/IPv6 endpoints -- and the problem of what to specify in = the answer is the same, except in the case of SIP there's only one = control channel (the session itself). While the clarifications, and especially an informational examples = draft, could be helpful, it should come as a follow up to the = Offer/Answer RFCs (3264 and 4317), maybe with examples spanning multiple = control protocols, including MRCPv2. -- dan On Apr 20, 2011, at 1:24 AM, Wyss, Felix wrote: > Hi Eric, >=20 > It may be true that the IPv6 dependent parts of MRCP depend on other = RFCs, but I fear there will invariably be ambiguities that implementers = will have to make judgment calls on. Every time this happens, the = likelihood of interoperability issues increases. As this RFC introduces = new SDP attributes, I think it makes sense to proactively identify cases = where there may be a particular risk for impedance mismatches and = addressing them with examples and/or some prose -- even if = non-normative. =20 >=20 > I feel the "a=3Dcmid" attribute in particular has potential for such = ambiguities and think mixed IPv4/IPv6 environments are an area that = could benefit from guidance. At a minimum this will ensure implementers = are aware that there may be additional aspects to consider.=20 >=20 > Thanks, > --Felix >=20 >> -----Original Message----- >> From: Eric Burger [mailto:eburger@standardstrack.com] >> Sent: Monday, April 18, 2011 11:00 >> To: Wyss, Felix >> Cc: speechsc@ietf.org >> Subject: Re: [Speechsc] MRCP and mixed IPv4/IPv6 environments >>=20 >> This is a really good point. Especially in light of IPv4 exhaustion, = IPv6 >> should be on everybody's mind. >>=20 >> That said, while it would be extremely helpful to have IPv6 examples = in >> the published RFC, I am not sure the MRCPv2 document under-specifies = IPv6 >> use. Moreover, the speechsc work group will not be the place to work = out >> SDP IPv6 issues. The good news is according to the SIPit 24 report, >> almost 70% of implementations came with IPv6 SIP stacks, so we are = well on >> our way to proving interoperability. >>=20 >> Especially since IETF Last Call completed last week, I would offer = that >> IPv6 examples could be a great follow-on Informational draft, if = people >> would like to work on it. >>=20 >>=20 >> On Apr 17, 2011, at 1:09 AM, Wyss, Felix wrote: >>=20 >>> The examples in the most recent draft (draft-ietf-speechsc-mrcpv2- >> 24.txt) use only IPv4 address types. There is no mention of IPv6, = let >> alone how MRCP should be used in mixed IPv4/IPv6 environments. I = think >> that should be addressed in the RFC, at a minimum with some examples >> and/or discussion to provide guidance to implementers. This seems >> especially important as the introduction of the "a=3Dcmid" co-media >> attribute adds another dimension to the media negotiation. >>>=20 >>> As an example, I took a synthesizer sample from the current draft = and >> tried to come up with an offer/answer exchange in a mixed environment = with >> alternate address type semantics (RFC#4091). I am assuming here that = the >> offerer allows the answerer to accept a different address type for = MRCP >> and RTP by listing both stream identifiers of the IP4 and IP6 RTP = streams >> as two separate "a=3Dcmid" attributes. Thus, the answerer could = elect to >> use IPv6 for MRCP and IPv4 for RTP: >>>=20 >>>=20 >>> Offer: >>>=20 >>> v=3D0 >>> o=3Dsarvi 2890844526 2890844526 IN IP6 2001:DB8::4 >>> s=3D- >>> a=3Dgroup:ANAT 1 2 >>> a=3Dgroup:ANAT 3 4 >>> m=3Dapplication 9 TCP/MRCPv2 1 >>> c=3DIN IP4 192.0.2.12 >>> a=3Dsetup:active >>> a=3Dconnection:new >>> a=3Dresource:speechsynth >>> a=3Dcmid:3 >>> a=3Dcmid:4 >>> a=3Dmid:1 >>> m=3Dapplication 9 TCP/MRCPv2 1 >>> c=3DIN IP6 2001:DB8::1 >>> a=3Dsetup:active >>> a=3Dconnection:new >>> a=3Dresource:speechsynth >>> a=3Dcmid:3 >>> a=3Dcmid:4 >>> a=3Dmid:2 >>> m=3Daudio 49170 RTP/AVP 0 >>> c=3DIN IP4 192.0.2.12 >>> a=3Drtpmap:0 pcmu/8000 >>> a=3Drecvonly >>> a=3Dmid:3 >>> m=3Daudio 49170 RTP/AVP 0 >>> c=3DIN IP6 2001:DB8::1 >>> a=3Drtpmap:0 pcmu/8000 >>> a=3Drecvonly >>> a=3Dmid:4 >>>=20 >>>=20 >>> Example Answer 1 (IPv6 for MRCP, IPv6 for RTP): >>>=20 >>> v=3D0 >>> o=3D 2890842808 2890842808 IN IP6 2001:DB8::5 >>> s=3D- >>> m=3Dapplication 0 TCP/MRCPv2 1 >>> c=3DIN IP4 0.0.0.0 >>> a=3Dmid:1 >>> m=3Dapplication 32416 TCP/MRCPv2 1 >>> c=3DIN IP6 2001:DB8::2 >>> a=3Dsetup:passive >>> a=3Dconnection:new >>> a=3Dchannel:32AECB234338@speechsynth >>> a=3Dcmid:4 >>> a=3Dmid:2 >>> m=3Daudio 0 RTP/AVP 0 >>> c=3DIN IP4 0.0.0.0 >>> a=3Dmid:3 >>> m=3Daudio 48260 RTP/AVP 0 >>> c=3DIN IP6 IN IP6 2001:DB8::2 >>> a=3Drtpmap:0 pcmu/8000 >>> a=3Dsendonly >>> a=3Dmid:4 >>>=20 >>>=20 >>> Example Answer 2 (IPv6 for MRCP, IPv4 for RTP): >>>=20 >>> v=3D0 >>> o=3D 2890842808 2890842808 IN IP6 2001:DB8::5 >>> s=3D- >>> m=3Dapplication 0 TCP/MRCPv2 1 >>> c=3DIN IP4 0.0.0.0 >>> a=3Dmid:1 >>> m=3Dapplication 32416 TCP/MRCPv2 1 >>> c=3DIN IP6 2001:DB8::2 >>> a=3Dsetup:passive >>> a=3Dconnection:new >>> a=3Dchannel:32AECB234338@speechsynth >>> a=3Dcmid:3 >>> a=3Dmid:2 >>> m=3Daudio 48260 RTP/AVP 0 >>> c=3DIN IP4 192.0.2.11 >>> a=3Drtpmap:0 pcmu/8000 >>> a=3Dsendonly >>> a=3Dmid:3 >>> m=3Daudio 0 RTP/AVP 0 >>> c=3DIN IP6 :: >>> a=3Dmid:4 >>>=20 >>>=20 >>> Does that seem like an appropriate interpretation? >>>=20 >>> Thanks, >>> Felix Wyss >>> Interactive Intelligence, Inc. >>>=20 >>> _______________________________________________ >>> Speechsc mailing list >>> Speechsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/speechsc >>> Supplemental web site: >>> <http://www.standardstrack.com/ietf/speechsc> >=20 >=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> From dburnett@voxeo.com Sun Oct 30 18:25:21 2011 Return-Path: X-Original-To: speechsc@ietfa.amsl.com Delivered-To: speechsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ACE11E80A2; Sun, 30 Oct 2011 18:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lL8mJ6OyLGu; Sun, 30 Oct 2011 18:25:21 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id D1A5D11E80A4; Sun, 30 Oct 2011 18:25:20 -0700 (PDT) Received: from [209.237.253.51] (account dburnett@voxeo.com HELO [10.119.5.202]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 98386219; Mon, 31 Oct 2011 01:20:22 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dan Burnett In-Reply-To: Date: Sun, 30 Oct 2011 21:20:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110316191330.15705.6182.idtracker@localhost> To: Slawomir Testowy X-Mailer: Apple Mail (2.1084) Cc: speechsc@ietf.org, ietf@ietf.org Subject: Re: [Speechsc] Last Call: (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 01:25:22 -0000 On Apr 18, 2011, at 3:10 AM, Slawomir Testowy wrote: > Hi! >=20 > Some other comments: >=20 >> 4.2. Managing Resource Control Channels >=20 >> When the client wants to add a media processing resource to the >> session, it issues a SIP re-INVITE transaction. >=20 > Is it possible to allocate more than one resource of the same type > during one SIP dialog? Example in 4.2 shows how to allocate > synthesizer and recognizer, but does not specify if there may be e.g. > more than one synthesizer. No, it is not possible. There is no way, for example, to specify which = recognizer is being deleted when you deallocate one. I will clarify = this restriction in the specification. >=20 >=20 >=20 >> 6.2.9. Content-Encoding >>=20 >>=20 >> The content-encoding entity-header is used as a modifier to the >> media-type. When present, its value indicates what additional >> content encoding has been applied to the entity-body, and thus what >> decoding mechanisms must be applied in order to obtain the = media-type >> referenced by the content-type header field. Content-encoding is >> primarily used to allow a document to be compressed without losing >> the identity of its underlying media type. Note that the SDP = session >> can be used to determine accepted encodings (see Section 7). This >> header field MAY occur on all messages. >=20 > Section 7 describes usage of OPTIONS method of SIP and Accept-Encoding > header is returned by SIP response, not SDP answer, so I guess "Note = that > the SDP session can be used" should be changed to "Note that the SIP > session can be used". Good catch. I will make this change. >=20 >> When a CONTROL request to jump backward is issued to a currently >> speaking synthesizer resource, and the target jump point is before >> the start of the current "SPEAK" request, the current "SPEAK" = request >> MUST restart from the beginning of its speech data and the response >> to the CONTROL request MUST contain this header field with a value = of >> "true" indicating a restart. >=20 > Why sometimes requests are surrounded by quotation marks (like = "SPEAK") > and sometimes not (like CONTROL request)? This happens through all the > specification. This may be a minor nit, but makes the whole paper look = like a > "draft" :) This is an artifact of having had multiple editors over the years :) I = will correct this. >=20 >> 8.4.7. Prosody-Parameters >=20 >> The prosody parameter headers in the "SET-PARAMS" or "SPEAK" request >> only apply if the speech data is of type text/plain and does not use >> a speech markup format. >=20 > Why is it so? Why it is not true for Voice-Parameters? Technically they are similar in that both can be specified within SSML. = However, this distinction is a subtle one and reflects common practice = in voice output design -- a designer is more likely to want to specify a = default voice as a header than default prosody, because the former is = commonly needed for a document as a whole (even though it can be changed = within a document) while the latter typically only applies to specific = text (even though one could change it for the document as a whole). > Is it true for CONTROL (i.e. current SPEAK must be text/plain)? The distinction between Prosody and Voice parameters applies in the case = of CONTROL as well. >=20 > Specification does not say anything about it. >=20 >> 8.4.16. Load-Lexicon >>=20 >>=20 >> This header field is used to indicate whether a lexicon has to be >> loaded or unloaded. The default value for this header field is >> "true". This header field MAY be specified in a DEFINE-LEXICON >> method. >=20 > I propose rewording this paragraph to explicilty state that "true" = means > "load lexicon" and "false" means "unload lexicon". This is a good clarification. I will add it. >=20 >=20 >=20 > Thanks. > Slawek Testowy >=20 >=20 >=20 >=20 > 2011/3/16 The IESG : >>=20 >> The IESG has received a request from the Speech Services Control WG >> (speechsc) to consider the following document: >> - 'Media Resource Control Protocol Version 2 (MRCPv2)' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional = two >> weeks for review since the document is large and the review period = overlaps >> the Prague IETF meeting). Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/ >>=20 >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/ >>=20 >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> Speechsc mailing list >> Speechsc@ietf.org >> https://www.ietf.org/mailman/listinfo/speechsc >> Supplemental web site: >> <http://www.standardstrack.com/ietf/speechsc> >>=20 > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc>