Subject: RE: [Speechsc] query Simultaneous RECOGNIZE and RECORD MRCP media requests on the same media

From: "Saravanan Shanmugham \(sarvi\)" <[email-masked]>
Date: Wed, 8 Nov 2006 10:49:25 -0800

When you setup your media and control channels, you associate the
control channels(resource) to the media channel. Within a single MRCP
session A single media channel can be associated with more that one
control channel i.e resource. So the resources can share and process
that single channel. In the server this may be implemented through
forking to the 2 resources or whatever other means is appropriate for
the server implementation. 

So, Yes, you can issue a RECORD on the recorder resource while at the
same time issuing a RECOGNIZE on the recognizer resource. The protocol
allows this. The question is whether a particular MRCP server
implementation supports this.

Now, if the recorder and recognizer are on different servers, they are
separate MRCP sessions. Here the control channels(resources), will not
be able to share a media pipe.  But this is not say the client may not
fork its media source 2-ways  and send them to the recognizer and
recorder resources separately.

Thx,
Sarvi

     -----Original Message-----
     From: Srinivas R Thota [mailto:[email-masked]] 
     Sent: Tuesday, November 07, 2006 11:06 PM
     To: [email-masked]
     Subject: [Speechsc] query Simultaneous RECOGNIZE and 
     RECORD MRCP media requests on the same media
     
     Hi ,
     
     Can RECOGNIZE and RECORD MRCP media requests on the same media ?
     (for example for a use-case wherein user utterances have 
     to be record while attempting recognition. ) I know that 
     the same can be archived using save-waveform header in 
     RECOGNIZE, but is it possible to do media-forking between 
     Recognizer and Recorder which are different resources and 
     archive this, does it have any specific problem.
     Can this work even if  Recognizer and Recorder on 
     different systems. ?
     
     Thanks & Regards,
     Srinivas R Thota
     
     -- 
     
     --
     ***********************************************************
     ****************************
     	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!

     _______________________________________________
     Speechsc mailing list
     [email-masked]
     https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: sreekanth <[email-masked]>
Date: Wed, 22 Nov 2006 12:26:52 +0530

This is a quote from the section 6.2 of mrcpv2-draft-11

message-header = field-name ":" [ field-value ]

field-name = token

field-value = *LWS field-content *( CRLF 1*LWS field-content)

field-content = <the OCTETs making up the field-value

and consisting of either *TEXT or combinations

of token, separators, and quoted-string>

As per the above rule if the header if of list type,  is it  mandatory that the multiple header values MUST have atleast one LWS???

In the header ABNF already seperator for the multiple values is defined.. So Why do we need this LWS??

Pls clarify on this.

Sreekanth

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 23 Nov 2006 11:31:03 -0000

Hi Sreekanth,

This is the general format of all headers, and the concept is consistent 
across many protocols including SMTP, HTTP and SIP.  This general rule 
allows you to readily find the beginning of headers without having to do 
detailed parsing of each header (e.g. just look for non-white space after CR 
LF).  It also allows you to skip over, possibly ignorable, headers that may 
not be defined yet.

BTW - this isn't just for list type headers.  It can be used for any header 
that benefits from being spread across multiple lines. e.g.:

MyHeader: foo
    bar
    do
    da
    =
    18

To the doc authors:
--------------------
I note that section 6.2 says: "The value MAY be preceded by any amount of 
LWS, though a single SP is preferred."  However, most of the examples don't 
include a space.  Maybe no space is preferred for MRCP?

Also, I can't find anywhere that says whether the EBNF grammar is explicit 
about where white space can be included or not.  Some rules suggest that it 
is and some rules imply that it is not (i.e. no mention of optional WS). 
Sorry if this has been raised before.

And, just in case it's not been raised before, should the EBNF for the 
method name and message-header be made extensible? e.g. something like:

method-name      =    generic-method
                 /    synthesizer-method
                 /    recorder-method
                 /    recognizer-method
                 /    verifier-method
                 /    token   ; <------

message-header   =    1*(generic-header / resource-header / 
extension-header)

extension-header = field-name ":" [ field-value ]

If appropriate, perhaps these issues can be discussed at the start of the 
EBNF section (15).

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "sreekanth" <[email-masked]>
To: "Saravanan Shanmugham (sarvi)" <[email-masked]>; "Dan Burnett" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 22, 2006 6:56 AM
Subject: [Speechsc] Query in the general message header ABNF

> As per the above rule if the header if of list type,  is it  mandatory 
> that the multiple header values MUST have atleast one LWS???
>

--------------------------------------------------------------------------------