From speechsc-bounces@ietf.org Wed Jan 09 08:11:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaiS-0004lY-Q9; Wed, 09 Jan 2008 08:11:32 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JCGPH-0008MI-0x for speechsc-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 10:30:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGPG-00086H-An; Tue, 08 Jan 2008 10:30:22 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCGPA-00069U-IU; Tue, 08 Jan 2008 10:30:17 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m08FTwDM018178; Tue, 8 Jan 2008 09:29:58 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m08FTqj02018; Tue, 8 Jan 2008 09:29:59 -0600 (CST) Message-ID: <478396EF.3090502@alcatel-lucent.com> Date: Tue, 08 Jan 2008 09:29:51 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dburnett@voxeo.com, sarvi@cisco.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 1.5 (+) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 X-Mailman-Approved-At: Wed, 09 Jan 2008 08:11:32 -0500 Cc: IETF SIP List , speechsc@ietf.org, speechsc-chairs@tools.ietf.org Subject: [Speechsc] Review of draft-ietf-speechsc-mrcpv2-15 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Hi: The following is a review of draft-ietf-speechsc-mrcpv2-15 with emphasis on S1-S5, S12 and S14. There are a few general comments first; the rest of the comments follow in linear fashion with respect to the sections enumerated above. General comment 1: ------------------ A general comment I have is what is the relationship of MRCPv2 with RTSP? Both of these seem to provide some similar functionality, such as a recording resource. Also, RFC4463, the precursor to MRCPv2 appears to discuss RTSP more than this document does. In this document, SIP essentially replaces RTSP as the preferred protocol to establish a control session. This is fine, but it would seem to me that the average reader familiar with RTSP may benefit from some thoughts about the relationship of MRCPv2 to RTSP. General comment 2: ------------------ Another general comment I have concerns the SIP message flow in S4.2. There are a number of tactical omissions and implicit assumptions in that call flow that are repeated in the call flows of other sections as well. I will list these out for S4.2 and trust that the authors will retrofit other sections based on this discussion. 1. On page 15, when the C->S, the R-URI of the request is shown as sip:mresources@server.example.com. While this is not inaccurate, what will typically happen in SIP is that the initial request is targeted to a domain (i.e., sip:mresources@example.com) instead of a specific server within that domain (i.e., sip:mresources@server.example.com). Once the SIP dialog has been established, subsequent requests will contain a R-URI that is reflective of the specific server within that domain. Thus, on the very first request of a dialog-forming method like INVITE, you may want to consider changing the R-URI to reflect the domain URI of "sip:mresources@example.com". When that server replies with a 200 OK, the Contact URI of that response will contain a FQDN (i.e., "sip:mresources@server.example.com") -- and this is indeed the case in your call flow (see 200 OK on Page 16.) Note that subsequent requests in the dialog will contain a R-URI that corresponds to the FQDN of the server. Thus, in S4.2, at the end of page 16, the R-URI of the server is accurately shown as being "sip:mresources@server.example.com". 2. On page 15, the Contact URI of the initial INVITE request should contain a specific client within that domain. That is, the Contact URI must be "sip:sarvi@client.example.com" and not "sip:sarvi@example.com". 3. In SIP, a LWS is used to denote continuation. Thus, instead of writing: Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf9 you must instead write: Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf9 Note the LWS on the second line above. 4. In SIP, when a server responds with an affirmative response, it always adds a tag parameter to the From header. In the call flow on page 16, the From header of the 200 OK does not contain a tag parameter, it must. Interestingly enough, the subsequent ACK request contains the tag in the From parameter (as indeed it should.) Please add a tag parameter to the From header in the 200 OK, and ensure that it matches the one in the ACK request. The tags are maintained for the duration of the lifetime of that dialog. Thus, in the re-INV that starts at the bottom of page 16, the From tag must be maintained. Aside: the second m= line in the 200 OK body should have one 0 (i.e., s/00/0). 5. In SIP, the CSeq number of the ACK is kept the same as the preceding INVITE. Thus, on page 16 the CSeq number of the ACK request must be 314161. General comment 3: ------------------ In S6.1.1, page 29, there is an example message: MRCP/2.0 124 SET-PARAMS 543256 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:female Voice-variant:3 The second token (124) refers to the message length of the message, including the message body, if any. In the above example, if I assume that each line is terminated by a '\n' and a '\r\n' terminates the message itself, then I come up with a message length of 115 octets, which does not match the value shown above of 124. I would advise that, for the sake of completeness, the message-length field matches the actual value of the number of octets in the message for this example as well as the rest of the examples in the draft, including the examples in S14. As another example, take a look at the S->C message at the end of page 42 in S7. I calculate the payload length to be 291 octets, which does not match the Content-Length field value of 269 in the example. I would advise that, for the sake of completeness, the Content-Length field value matches the actual value of the number of octets in the SIP message body for this example as well as the rest of the examples in the draft. General comment 4: ------------------ The state machines in the draft are depicted as a time-flow diagram -- this is interesting. While I have not seen a state machine depicted as such -- all of the ones I am used to employ the canonical vertex and edges between them to signify transitions -- if a time-flow diagram suffices for the population reading the draft, then I am perfectly fine with leaving it in as is. I will depend on your discretion to strike out this comment if the depiction of the state machine is consistent with reader expectations. Rest of my comments follow: - Abstract: It is stated that MRCPv2 "relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery." True, SIP is a rendezvous protocol, but in and of itself, it is not a (media) capability discovery protocol; SDP is probably closer to the mark for (media) capability discovery and description (incidentally, SDP is mentioned in the immediate next sentence.) I would suggest a modest re-write, something along these lines: OLD: - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP ... NEW: - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 client 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 ... - S1, second paragraph: It is stated that "In addition, the client can use a SIP re-INVITE method (an INVITE dialog sent within an existing SIP Session) to change the characteristics of these media and control session while maintaining the SIP dialog between the client and server." It is true that you can use re-INV to do what is mentioned. However, I am curious: did you consider the UPDATE method? It also allows a client to update the parameters of a session, but is lightweight than the re-INV (for instance, it does not require an ACK, and does not require the server to keep retransmission state of the response until it gets an ACK.) Now, using a re-INV for offer/answer is sometimes advantageous in situations where, for instance, the sender wants to send a re- INV but does not specify any offer in it. The receiver sends an offer in the 2xx, and the sender answers that offer in the ACK. But I do not see MRCPv2 using such an exchange in the call flows present in the document. These call flows are of the normal pattern of "offer in request, answer in response". I realize that call flows do not normatively reflect the text, but if MRCPv2 can benefit from some reduced complexity by using a UPDATE/200 to change the session characteristics, then why not think about it? I will leave the final decision to you. - S1, third paragraph, first line: consider taking out the phrase "client/server" from the sentence. In SIP, once a dialog is set up, either end can act as a client. - S2.1: There appears to be some formatting problems. The second column invariably starts at a line below the first column. S3.1: Same comment as above when describing the media processing resources. - S2.2: Given that the reader of this document has no idea (at this point in the document) what PENDING, IN-PROGRESS, or COMPLETE are, you may wish to consider moving this paragraph before the first state diagram, by which time these states would have been explained. Or alternatively, you may want to consider putting a forward reference to S5.3, where these states are defined. - S3, third paragraph: s/server using this/server on this/ - S3, third paragraph: You may want to put a forward reference to the framing issue when doing I/O over a stream transport. When I was reading this paragraph, it naturally occurred to me whether MRCPv2 provides framing (it does, and this is discussed in S5.) Same comment as above for the opening paragraph of S4. - S3.1, in the definition of a Recorder: s/A resource capable of recording audio and saving it to a URI./A resource capable of recording audio and saving it as resource accessible by a URI./ - S3.1, in the defintion of a Recorder, second line: s/end pointing// - S3.2: the opening paragraph can best be re-written as follows: The MRCPv2 server is a generic SIP server, and is thus addressed by a SIP URI, for example: sip:mrcpv2@example.net. This is more concise, and I believe sufficient. How this address is resolved to reach the SIP server, and how that SIP server registers with its registrar are all handled by rfc3261. I do not see any advantage of discussing SIP registrars and Contact URIs here. - S4.1, third line: s/SIP transactions/SIP requests/ - S4.3, page 21: s/and fork it/and give it/ - S4.3, last paragraph: I am always a proponent of better error diagnostics. Thus, instead of putting the stock reason-phrase of "Not Implemented" on the 501 status-code, why not be more descriptive and put a reason-phrase of "Cannot mix/multimix or fork media"? That allows the automata to consume the 501 status-code as intended, but also allows for a descriptive reason-phrase to be displayed to the user. - S5.1, page 22: In the ABNF for generic-message, the generic- header production rule is not expanded until S6.2. I would suggest that it be expanded in S5.1, along with the resource- header production rule, or barring that, at least a forward reference to S6.2 be maintained to let the reader quickly find where generic-header is expanded. - S5.1: It may be best to move the discussion of the message-length field on page 23 to S5.2. It fits better there since the token is described in S5.2. Otherwise, you straddle critical information in between two sections and the reader has to go back and forth to make sense (BTW, FWIW, I am glad you have this field; framing is made much easier and code can be optimized by having it.) Same comment for mrcp-version production rule; describe it in S5.2 as well. - S5.2: I think it may be best if you describe the fields in the order that they appear in the request-line production rule. So, describe mrcp-version production rule first, followed by message-length, and so on. And consider consolidating the description of mrcp-version and message-length from S5.1 to this section (see previous comment.) As an added incentive to do this, note that in S5.3, the order of description matches the order in which the tokens appear in the response-line production rule. - S5.4: I note that you have some sort of an asynchronous notification system of responses (i.e., a PENDING or IN-PROGRESS indicates further Event messages will be delivered.) Why not have an specific status-code to that effect? In SIP, we have the notion of a "202 Accepted" response, which indicates that a request has been accepted but yet to be fully processed. Would a 202 response code be valuable to MRCPv2? I cannot say for sure, but did want to point this out to you so you can make a judgment on whether this is indeed the case. If you would like to read up more on the semantics of the 202 response code in SIP, it is defined in rfc3265. - S5.5, first paragraph: s/The status value is COMPLETE/The request- state value is COMPLETE/ Also, same comment as in S5.2 about making sure that the description of the tokens in the event-line production rule match the order in which the tokens appear in the production rule. - S7: missing terminating period on the last sentence of the section (end of page 42.) - The state machines in the draft are depicted as a time-flow diagram -- this is interesting. While I have not seen a state machine depicted as such -- all of the ones I am used to employ the canonical vertex and edges between them to signify transitions -- if a time-flow diagram suffices for the population reading the draft, then I am perfectly fine with leaving it in as is. I will depend on your discretion to strike out this comment if the depiction of the state machine is consistent with reader expectations. - S12.3 - Does anything need to be said about how to key the SRTP stream? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Jan 09 08:11:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaiT-0004lx-5B; Wed, 09 Jan 2008 08:11:33 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JCI3H-0006li-Po for speechsc-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI3H-0006lZ-Fr; Tue, 08 Jan 2008 12:15:47 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI3H-0004Ef-5C; Tue, 08 Jan 2008 12:15:47 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m08HFfid029515; Tue, 8 Jan 2008 11:15:41 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m08HFgj05609; Tue, 8 Jan 2008 11:15:42 -0600 (CST) Message-ID: <4783AFBD.50905@alcatel-lucent.com> Date: Tue, 08 Jan 2008 11:15:41 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <478396EF.3090502@alcatel-lucent.com> <4783AF11.9030406@cisco.com> In-Reply-To: <4783AF11.9030406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Wed, 09 Jan 2008 08:11:32 -0500 Cc: IETF SIP List , sarvi@cisco.com, speechsc-chairs@tools.ietf.org, speechsc@ietf.org Subject: [Speechsc] Re: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Paul Kyzivat wrote: > Vijay, > > A very thorough review. I have one comment on it, below. > > > Vijay K. Gurbani wrote: > >> 4. In SIP, when a server responds with an affirmative response, >> it always adds a tag parameter to the From header. > > Don't you mean To: header? Paul: Yes, my bad. Thanks for catching this. Indeed, I meant the To header. > The initial INVITE should have a From-tag and the response should > contain that and a To-tag. All subsequent requests and responses in the > dialog should have both. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Jan 09 08:11:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaiS-0004lq-Vm; Wed, 09 Jan 2008 08:11:32 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JCI0X-0005fZ-Rj for speechsc-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:12:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI0X-0005fQ-EB; Tue, 08 Jan 2008 12:12:57 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mFrom speechsc-bounces@ietf.org Wed Jan 09 08:11:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaiT-0004lx-5B; Wed, 09 Jan 2008 08:11:33 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JCI3H-0006li-Po for speechsc-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI3H-0006lZ-Fr; Tue, 08 Jan 2008 12:15:47 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI3H-0004Ef-5C; Tue, 08 Jan 2008 12:15:47 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m08HFfid029515; Tue, 8 Jan 2008 11:15:41 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m08HFgj05609; Tue, 8 Jan 2008 11:15:42 -0600 (CST) Message-ID: <4783AFBD.50905@alcatel-lucent.com> Date: Tue, 08 Jan 2008 11:15:41 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <478396EF.3090502@alcatel-lucent.com> <4783AF11.9030406@cisco.com> In-Reply-To: <4783AF11.9030406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Wed, 09 Jan 2008 08:11:32 -0500 Cc: IETF SIP List , sarvi@cisco.com, speechsc-chairs@tools.ietf.org, speechsc@ietf.org Subject: [Speechsc] Re: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Paul Kyzivat wrote: > Vijay, > > A very thorough review. I have one comment on it, below. > > > Vijay K. Gurbani wrote: > >> 4. In SIP, when a server responds with an affirmative response, >> it always adds a tag parameter to the From header. > > Don't you mean To: header? Paul: Yes, my bad. Thanks for catching this. Indeed, I meant the To header. > The initial INVITE should have a From-tag and the response should > contain that and a To-tag. All subsequent requests and responses in the > dialog should have both. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Jan 09 08:11:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCaiS-0004lq-Vm; Wed, 09 Jan 2008 08:11:32 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JCI0X-0005fZ-Rj for speechsc-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 12:12:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCI0X-0005fQ-EB; Tue, 08 Jan 2008 12:12:57 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCI0U-0004Bj-Vc; Tue, 08 Jan 2008 12:12:57 -0500 X-IronPort-AV: E=Sophos;i="4.24,258,1196658000"; d="scan'208";a="82700040" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jan 2008 12:12:54 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m08HCsa5023261; Tue, 8 Jan 2008 12:12:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m08HCOqA022700; Tue, 8 Jan 2008 17:12:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:12:48 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:12:48 -0500 Message-ID: <4783AF11.9030406@cisco.com> Date: Tue, 08 Jan 2008 12:12:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <478396EF.3090502@alcatel-lucent.com> In-Reply-To: <478396EF.3090502@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2008 17:12:48.0144 (UTC) FILETIME=[B13F6100:01C85219] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1259; t=1199812374; x=1200676374; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-speech sc-mrcpv2-15 |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=UCtKtK0nNofSnkxkkIES1fcmqPxXZ6/RikTWjhmg1vI=; b=ZtOm8gTe+uWE7rrQna4eyu6UNFzr0f5XnDfAzlnXCVchX2OwK8GaLBgHX/ oaDP5BtpziTGrnvckHvpypNJBSMhvDQvLGwUiNI2/01kEEaJfm/GxesxTCOH 8j9m9ftd8q; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 09 Jan 2008 08:11:32 -0500 Cc: IETF SIP List , sarvi@cisco.com, speechsc-chairs@tools.ietf.org, speechsc@ietf.org Subject: [Speechsc] Re: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Vijay, A very thorough review. I have one comment on it, below. Thanks, Paul Vijay K. Gurbani wrote: > Hi: > > The following is a review of draft-ietf-speechsc-mrcpv2-15 with > emphasis on S1-S5, S12 and S14. There are a few general comments > first; the rest of the comments follow in linear fashion with respect > to the sections enumerated above. [snip] > 4. In SIP, when a server responds with an affirmative response, > it always adds a tag parameter to the From header. Don't you mean To: header? The initial INVITE should have a From-tag and the response should contain that and a To-tag. All subsequent requests and responses in the dialog should have both. > In the call > flow on page 16, the From header of the 200 OK does not contain > a tag parameter, it must. Interestingly enough, the subsequent > ACK request contains the tag in the From parameter (as indeed it > should.) Please add a tag parameter to the From header in the > 200 OK, and ensure that it matches the one in the ACK request. > The tags are max.ietf.org with esmtp (Exim 4.43) id 1JCI0U-0004Bj-Vc; Tue, 08 Jan 2008 12:12:57 -0500 X-IronPort-AV: E=Sophos;i="4.24,258,1196658000"; d="scan'208";a="82700040" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jan 2008 12:12:54 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m08HCsa5023261; Tue, 8 Jan 2008 12:12:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m08HCOqA022700; Tue, 8 Jan 2008 17:12:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:12:48 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:12:48 -0500 Message-ID: <4783AF11.9030406@cisco.com> Date: Tue, 08 Jan 2008 12:12:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <478396EF.3090502@alcatel-lucent.com> In-Reply-To: <478396EF.3090502@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2008 17:12:48.0144 (UTC) FILETIME=[B13F6100:01C85219] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1259; t=1199812374; x=1200676374; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Review=20of=20draft-ietf-speech sc-mrcpv2-15 |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=UCtKtK0nNofSnkxkkIES1fcmqPxXZ6/RikTWjhmg1vI=; b=ZtOm8gTe+uWE7rrQna4eyu6UNFzr0f5XnDfAzlnXCVchX2OwK8GaLBgHX/ oaDP5BtpziTGrnvckHvpypNJBSMhvDQvLGwUiNI2/01kEEaJfm/GxesxTCOH 8j9m9ftd8q; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 09 Jan 2008 08:11:32 -0500 Cc: IETF SIP List , sarvi@cisco.com, speechsc-chairs@tools.ietf.org, speechsc@ietf.org Subject: [Speechsc] Re: [Sip] Review of draft-ietf-speechsc-mrcpv2-15 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Vijay, A very thorough review. I have one comment on it, below. Thanks, Paul Vijay K. Gurbani wrote: > Hi: > > The following is a review of draft-ietf-speechsc-mrcpv2-15 with > emphasis on S1-S5, S12 and S14. There are a few general comments > first; the rest of the comments follow in linear fashion with respect > to the sections enumerated above. [snip] > 4. In SIP, when a server responds with an affirmative response, > it always adds a tag parameter to the From header. Don't you mean To: header? The initial INVITE should have a From-tag and the response should contain that and a To-tag. All subsequent requests and responses in the dialog should have both. > In the call > flow on page 16, the From header of the 200 OK does not contain > a tag parameter, it must. Interestingly enough, the subsequent > ACK request contains the tag in the From parameter (as indeed it > should.) Please add a tag parameter to the From header in the > 200 OK, and ensure that it matches the one in the ACK request. > The tags are maintained for the duration of the lifetime of that > dialog. > > Thus, in the re-INV that starts at the bottom of page 16, the > From tag must be maintained. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> intained for the duration of the lifetime of that > dialog. > > Thus, in the re-INV that starts at the bottom of page 16, the > From tag must be maintained. _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> From speechsc-bounces@ietf.org Wed Jan 16 03:42:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3qT-0008L4-AN; Wed, 16 Jan 2008 03:42:01 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JF3qR-0008Kb-Ol for speechsc-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:41:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3qR-0008KT-EU for speechsc@ietf.org; Wed, 16 Jan 2008 03:41:59 -0500 Received: from web52707.mail.re2.yahoo.com ([206.190.48.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JF3qO-0008AL-ED for speechsc@ietf.org; Wed, 16 Jan 2008 03:41:59 -0500 Received: (qmail 64177 invoked by uid 60001); 16 Jan 2008 08:41:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=31zZSu/ZuzRm9iGa0BUxaNmPQ0qSseSW7wuHQGLuB1JRt387+TRck22P2kM9u+2XiYdZc0wZdT3yPx6jieiikMBGk10tiKfNBWwg/PIZK4i46YkpLiE76LyU1z3zbT4c4DDFA0BBgIMuJlzLvS8sho4wnxopokhYfXvDzXcIxok=; X-YMail-OSG: _1e7yTEVM1mBXkKhrqt0parZ6Z5NuNlKt9YlUzJt4tz4SFH66ZU13whrqam_al3amQ-- Received: from [195.69.162.137] by web52707.mail.re2.yahoo.com via HTTP; Wed, 16 Jan 2008 00:41:56 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.160 Date: Wed, 16 Jan 2008 00:41:56 -0800 (PST) From: Arsen Chaloyan To: speechsc@ietf.org MIME-Version: 1.0 Message-ID: <75658.63976.qm@web52707.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Speechsc] Concurrent requests in the same MRCP session scope X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096523353==" Errors-To: speechsc-bounces@ietf.org --===============1096523353== Content-Type: multipart/alternative; boundary="0-1433167476-1200472916=:63976" --0-1433167476-1200472916=:63976 Content-Type: text/plain; charset=us-ascii Can you please identify which from the following statements is true? 1. client MUST wait for a response before sending the next request in the same MRCP session scope or 2. client MAY send the next request without waiting for a response in the same MRCP session scope For example: 1. C->S: DEFINE-GRAMMAR [1] S->C: COMPLETE [1] C->S: RECOGNIZE [2] S->C: IN-PROGRESS [2] or 2. C->S: DEFINE-GRAMMAR [1] C->S: RECOGNIZE [2] S->C: COMPLETE [1] S->C: IN-PROGRESS [2] Thanks, Arsen. --0-1433167476-1200472916=:63976 Content-Type: text/html; charset=us-ascii
Can you please identify which from the following statements is true?
1. client MUST wait for a response before sending the next request in the same MRCP session scope
or
2. client MAY send the next request without waiting for a response in the same MRCP session scope

For example:
1. C->S: DEFINE-GRAMMAR [1]
    S->C: COMPLETE [1]
    C->S: RECOGNIZE [2]
    S->C: IN-PROGRESS [2]

or

2. C->S: DEFINE-GRAMMAR [1]
    C->S: RECOGNIZE [2]
    S->C: COMPLETE [1]
    S->C: IN-PROGRESS [2]

Thanks,
Arsen.
--0-1433167476-1200472916=:63976-- --===============1096523353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1096523353==-- From speechsc-bounces@ietf.org Wed Jan 16 03:53:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF41c-0005jr-8i; Wed, 16 Jan 2008 03:53:32 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JF41a-0005jZ-Pn for speechsc-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 03:53:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF41a-0005jQ-Aj for speechsc@ietf.org; Wed, 16 Jan 2008 03:53:30 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF41Y-00031c-Gr for speechsc@ietf.org; Wed, 16 Jan 2008 03:53:30 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUQ00JT5BBOYJ@szxga03-in.huawei.com> for speechsc@ietf.org; Wed, 16 Jan 2008 16:52:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUQ00G6RBBNMP@szxga03-in.huawei.com> for speechsc@ietf.org; Wed, 16 Jan 2008 16:52:36 +0800 (CST) Received: from manjuhtipl ([10.18.24.77]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUQ00J1CBBHSE@szxml03-in.huawei.com> for speechsc@ietf.org; Wed, 16 Jan 2008 16:52:35 +0800 (CST) Date: Wed, 16 Jan 2008 14:22:29 +0530 From: Manjunath Subject: RE: [Speechsc] Concurrent requests in the same MRCP session scope In-reply-to: <75658.63976.qm@web52707.mail.re2.yahoo.com> To: 'Arsen Chaloyan' , speechsc@ietf.org Message-id: <004301c8581d$23383080$4d18120a@china.huawei.com> Organization: Htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchYG+PXW1W07r/vRbyYB6ElHJFYmgAAST+Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manjunathan@huawei.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1602995548==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1602995548== Content-type: multipart/alternative; boundary="Boundary_(ID_eXIJY+OzUjV4qE66z+E9Vw)" This is a multi-part message in MIME format. --Boundary_(ID_eXIJY+OzUjV4qE66z+E9Vw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Second Statement is true.. Regards Manju **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Arsen Chaloyan [mailto:achaloyan@yahoo.com] Sent: Wednesday, January 16, 2008 2:12 PM To: speechsc@ietf.org Subject: [Speechsc] Concurrent requests in the same MRCP session scope Can you please identify which from the following statements is true? 1. client MUST wait for a response before sending the next request in the same MRCP session scope or 2. client MAY send the next request without waiting for a response in the same MRCP session scope For example: 1. C->S: DEFINE-GRAMMAR [1] S->C: COMPLETE [1] C->S: RECOGNIZE [2] S->C: IN-PROGRESS [2] or 2. C->S: DEFINE-GRAMMAR [1] C->S: RECOGNIZE [2] S->C: COMPLETE [1] S->C: IN-PROGRESS [2] Thanks, Arsen. --Boundary_(ID_eXIJY+OzUjV4qE66z+E9Vw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Second Statement is true..

 

Regards

Manju

 

***************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Arsen Chaloyan [mailto:achaloyan@yahoo.com]
Sent: Wednesday, January 16, 2008 2:12 PM
To: speechsc@ietf.org
Subject: [Speechsc] Concurrent requests in the same MRCP session scope

 

Can you please identify which from the following statements is true?
1. client MUST wait for a response before sending the next request in the same MRCP session scope
or
2. client MAY send the next request without waiting for a response in the same MRCP session scope

For example:
1. C->S: DEFINE-GRAMMAR [1]
    S->C: COMPLETE [1]
    C->S: RECOGNIZE [2]
    S->C: IN-PROGRESS [2]

or

2. C->S: DEFINE-GRAMMAR [1]
    C->S: RECOGNIZE [2]
    S->C: COMPLETE [1]
    S->C: IN-PROGRESS [2]

Thanks,
Arsen.

--Boundary_(ID_eXIJY+OzUjV4qE66z+E9Vw)-- --===============1602995548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1602995548==-- From speechsc-bounces@ietf.org Wed Jan 16 22:37:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFLZb-0002Ry-Cw; Wed, 16 Jan 2008 22:37:47 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JFLZa-0002Rt-01 for speechsc-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 22:37:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFLZZ-0002Rl-ME for speechsc@ietf.org; Wed, 16 Jan 2008 22:37:45 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFLZW-0000JK-Qr for speechsc@ietf.org; Wed, 16 Jan 2008 22:37:45 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUR00DL5RDJYG@szxga03-in.huawei.com> for speechsc@ietf.org; Thu, 17 Jan 2008 11:36:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUR00E70RDHWZ@szxga03-in.huawei.com> for speechsc@ietf.org; Thu, 17 Jan 2008 11:36:55 +0800 (CST) Received: from sharat1387 ([10.18.3.144]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUR001ZTRDC49@szxml03-in.huawei.com> for speechsc@ietf.org; Thu, 17 Jan 2008 11:36:53 +0800 (CST) Date: Thu, 17 Jan 2008 09:06:56 +0530 From: Sharat To: speechsc@ietf.org Message-id: <000701c858ba$35d63050$9003120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchYujUwTgJ8pa6XRduJ2eQMrt5MZg== X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fe59a790c76022cc05e0cda368f74f2 Subject: [Speechsc] Regarding SPEECH MARKER X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1594567053==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1594567053== Content-type: multipart/alternative; boundary="Boundary_(ID_EApbSLt3iWaQgQeDoHxenw)" This is a multi-part message in MIME format. --Boundary_(ID_EApbSLt3iWaQgQeDoHxenw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Consider the following scenarios for speechsynth. 1. C->S: SPEAK S->C: 200 PENDING S->C: SPEAK-COMPLETE 2. C->S: SPEAK S->C: 200 PENDING S->C: SPEECH-MARKER S->C: SPEAK-COMPLETE Are both the scenarios valid? Regds, __Sharat --Boundary_(ID_EApbSLt3iWaQgQeDoHxenw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

Consider the following scenarios for speechsynth.

1.

C->S: SPEAK

S->C: 200 PENDING

S->C: SPEAK-COMPLETE

2.

C->S: SPEAK

S->C: 200 PENDING

S->C: SPEECH-MARKER

S->C: SPEAK-COMPLETE

Are both the scenarios valid?

Regds,

__Sharat

 

--Boundary_(ID_EApbSLt3iWaQgQeDoHxenw)-- --===============1594567053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1594567053==-- From speechsc-bounces@ietf.org Thu Jan 17 02:02:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFOlM-0002kF-C4; Thu, 17 Jan 2008 02:02:08 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JFOlK-0002k2-Rv for speechsc-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 02:02:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFOlK-0002jt-Ev for speechsc@ietf.org; Thu, 17 Jan 2008 02:02:06 -0500 Received: from web52703.mail.re2.yahoo.com ([206.190.48.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFOlJ-0002zv-D9 for speechsc@ietf.org; Thu, 17 Jan 2008 02:02:06 -0500 Received: (qmail 2747 invoked by uid 60001); 17 Jan 2008 07:02:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=5o2x+5kmsRig0i9FulE5xcYKXsl3/FDlkbBYBZ1giuhjh4xYs+bmBqQU5m+Us/PGu2ricyZOBUX+SdnImas3SGTcn4WkGw7UDDMTq/ikor3FXQW+qD+8zaB7gbsLXmNkwpSSzh8YEwXBK0VDnomXcs8LjdNrXEsecQsHi+9dJAM=; X-YMail-OSG: XpyDrboVM1nzWu0bQQxCT.XSM7lDu6oMyy4Y32m2I_Ukbp4niQJA9A7r2WPSA6h7ORcIuwpe9g-- Received: from [195.69.162.137] by web52703.mail.re2.yahoo.com via HTTP; Wed, 16 Jan 2008 23:02:04 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.160 Date: Wed, 16 Jan 2008 23:02:04 -0800 (PST) From: Arsen Chaloyan Subject: Re: [Speechsc] Regarding SPEECH MARKER To: speechsc@ietf.org MIME-Version: 1.0 Message-ID: <897258.2508.qm@web52703.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ceb20e3ccfd90d068e2ad6c8a4781b53 Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1322196775==" Errors-To: speechsc-bounces@ietf.org --===============1322196775== Content-Type: multipart/alternative; boundary="0-1947907643-1200553324=:2508" --0-1947907643-1200553324=:2508 Content-Type: text/plain; charset=us-ascii Below is the reference from the specification Section 8.13. The SPEECH-MARKER event is also generated with a null marker value and output NTP timestamp, when a SPEAK request in Pending-State (i.e. in the queue) changes state to IN-PROGRESS and starts speaking. However it's not so clear whether event MUST be generated or MAY be generated. I'll vote to use the keywords to reduce unambiguity. HTH, Arsen. ----- Original Message ---- From: Sharat To: speechsc@ietf.org Sent: Thursday, January 17, 2008 7:36:56 AM Subject: [Speechsc] Regarding SPEECH MARKER Hi all, Consider the following scenarios for speechsynth. 1. C->S: SPEAK S->C: 200 PENDING S->C: SPEAK-COMPLETE 2. C->S: SPEAK S->C: 200 PENDING S->C: SPEECH-MARKER S->C: SPEAK-COMPLETE Are both the scenarios valid? Regds, __Sharat --0-1947907643-1200553324=:2508 Content-Type: text/html; charset=us-ascii
Below is the reference from the specification

Section 8.13.
The SPEECH-MARKER event is also generated with a null marker value and output NTP timestamp, when a SPEAK request in Pending-State (i.e. in the queue) changes state to IN-PROGRESS and starts speaking.

However it's not so clear whether event  MUST be generated or  MAY be generated. I'll vote to use the keywords to reduce unambiguity.
HTH,
Arsen.

----- Original Message ----
From: Sharat <sharatkk@huawei.com>
To: speechsc@ietf.org
Sent: Thursday, January 17, 2008 7:36:56 AM
Subject: [Speechsc] Regarding SPEECH MARKER

Hi all,

Consider the following scenarios for speechsynth.

1.

C->S: SPEAK

S->C: 200 PENDING

S->C: SPEAK-COMPLETE

2.

C->S: SPEAK

S->C: 200 PENDING

S->C: SPEECH-MARKER

S->C: SPEAK-COMPLETE

Are both the scenarios valid?

Regds,

__Sharat


--0-1947907643-1200553324=:2508-- --===============1322196775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============1322196775==-- From speechsc-bounces@ietf.org Thu Jan 17 02:16:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFOzh-0001LU-RB; Thu, 17 Jan 2008 02:16:57 -0500 Received: from speechsc by megatron.ietf.org with local (Exim 4.43) id 1JFOzf-0001L6-9q for speechsc-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 02:16:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFOze-0001Kv-UD for speechsc@ietf.org; Thu, 17 Jan 2008 02:16:54 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFOzZ-00038b-Ce for speechsc@ietf.org; Thu, 17 Jan 2008 02:16:54 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUS0049E1IXMY@szxga02-in.huawei.com> for speechsc@ietf.org; Thu, 17 Jan 2008 15:16:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JUS009Z31IVHD@szxga02-in.huawei.com> for speechsc@ietf.org; Thu, 17 Jan 2008 15:16:09 +0800 (CST) Received: from sharat1387 ([10.18.3.144]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JUS00JBO1IOJU@szxml04-in.huawei.com> for speechsc@ietf.org; Thu, 17 Jan 2008 15:16:07 +0800 (CST) Date: Thu, 17 Jan 2008 12:45:59 +0530 From: Sharat Subject: RE: [Speechsc] Regarding SPEECH MARKER In-reply-to: <897258.2508.qm@web52703.mail.re2.yahoo.com> To: 'Arsen Chaloyan' , speechsc@ietf.org Message-id: <000601c858d8$d043bea0$9003120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchY1uSB57moTNETSOyfQSZcT0IVGgAAHBXA X-Spam-Score: 0.0 (/) X-Scan-Signature: 1069eb5b3f212f2b9b575eaf2aff5119 Cc: X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0791423304==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0791423304== Content-type: multipart/alternative; boundary="Boundary_(ID_8O5RfRv2jNv6a8UdD6M10g)" This is a multi-part message in MIME format. --Boundary_(ID_8O5RfRv2jNv6a8UdD6M10g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Yes, it is not clearly mentioned anywhere in the RFC, whether the event MUST be generated or SHOULD be generated. Because of this ambiguity the client doesn't know whether it will receive SPEECH-MARKER or not from the server since it is dependent on the server implementation. As of now some of the mrcpv2 speechsynth servers support it and some doesn't. So while implementing client could receive either SPEECH-MARKER or SPEAK-COMPLETE in PENDING state. The rfc also says "The NTP timestamp MUST be synchronized with the RTP timestamp used to generate the speech stream through standard RTCP machinery." So the SPEECH-MARKER event is required to clearly demarcate between the RTP streams of two SPEAKs if queued in the same session. So I feel the keyword "MUST" has to be used. Regards, __Sharat _____ From: Arsen Chaloyan [mailto:achaloyan@yahoo.com] Sent: Thursday, January 17, 2008 12:32 PM To: speechsc@ietf.org Cc: Sharat Subject: Re: [Speechsc] Regarding SPEECH MARKER Below is the reference from the specification Section 8.13. The SPEECH-MARKER event is also generated with a null marker value and output NTP timestamp, when a SPEAK request in Pending-State (i.e. in the queue) changes state to IN-PROGRESS and starts speaking. However it's not so clear whether event MUST be generated or MAY be generated. I'll vote to use the keywords to reduce unambiguity. HTH, Arsen. ----- Original Message ---- From: Sharat To: speechsc@ietf.org Sent: Thursday, January 17, 2008 7:36:56 AM Subject: [Speechsc] Regarding SPEECH MARKER Hi all, Consider the following scenarios for speechsynth. 1. C->S: SPEAK S->C: 200 PENDING S->C: SPEAK-COMPLETE 2. C->S: SPEAK S->C: 200 PENDING S->C: SPEECH-MARKER S->C: SPEAK-COMPLETE Are both the scenarios valid? Regds, __Sharat --Boundary_(ID_8O5RfRv2jNv6a8UdD6M10g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

Yes, it is not clearly mentioned anywhere in the RFC, whether the event MUST be generated or SHOULD be generated.

Because of this ambiguity the client doesn’t know whether it will receive SPEECH-MARKER or not from the server since it is dependent on the server implementation.

As of now some of the mrcpv2 speechsynth servers support it and some doesn’t. So while implementing client could receive either SPEECH-MARKER or SPEAK-COMPLETE in PENDING state.

The rfc also says

“The NTP timestamp MUST be synchronized with the RTP timestamp used to generate the speech stream through standard RTCP machinery.”

So the SPEECH-MARKER event is required to clearly demarcate between the RTP streams of two SPEAKs if queued in the same session.

So I feel the keyword ”MUST”  has to be used.

Regards,

__Sharat

 

From: Arsen Chaloyan [mailto:achaloyan@yahoo.com]
Sent: Thursday, January 17, 2008 12:32 PM
To: speechsc@ietf.org
Cc: Sharat
Subject: Re: [Speechsc] Regarding SPEECH MARKER

 

Below is the reference from the specification

Section 8.13.
The SPEECH-MARKER event is also generated with a null marker value and output NTP timestamp, when a SPEAK request in Pending-State (i.e. in the queue) changes state to IN-PROGRESS and starts speaking.

However it's not so clear whether event  MUST be generated or  MAY be generated. I'll vote to use the keywords to reduce unambiguity.
HTH,
Arsen.

----- Original Message ----
From: Sharat <sharatkk@huawei.com>
To: speechsc@ietf.org
Sent: Thursday, January 17, 2008 7:36:56 AM
Subject: [Speechsc] Regarding SPEECH MARKER

Hi all,

Consider the following scenarios for speechsynth.

1.

C->S: SPEAK

S->C: 200 PENDING

S->C: SPEAK-COMPLETE

2.

C->S: SPEAK

S->C: 200 PENDING

S->C: SPEECH-MARKER

S->C: SPEAK-COMPLETE

Are both the scenarios valid?

Regds,

__Sharat

 

--Boundary_(ID_8O5RfRv2jNv6a8UdD6M10g)-- --===============0791423304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc Supplemental web site: <http://www.standardstrack.com/ietf/speechsc> --===============0791423304==--