Subject: [Speechsc] mrcpv2-01 comments

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Jan 2004 07:10:30 -0800

First, let me say I like it, thanks for all the hard work in. A bunch of
these comments may be that I just don't understand it well enough but here
are some thoughts/questions ....

When a devices fetches some document, when does it get rid of it.

Confusing how it is decided what parameters get set in SSML and what in MRCP
and what can be done in both. I don't really like the both solutions.

No audioplayer definition.

Section 2.2
Doe the user need to be mrcpv2 or is this just an example

Section 3.1, example 1, why bother opening a session before getting any
resources on it. 

Section 3.2 - defines  resource type of audioplayer but this is not defined
in the document 

Why did you pick a port of 9 when the port was unknown. Seems like 0 or
2^16-1 would be better?

If the server is on the inside of a NAT and the client on the outside, can
all of this work? Seems like you want the MRCPv2 control channel to open the
other direction. 

Example 3
I'm a little confused on how the listen ports on the TCP stuff work -
particularly when there are multiple of them. If I get two m control lines
that both have 32416 as the listen port at the far side, does that mean I
form two TCP connection to a TCP server listening on that port or I always
use one if it is the same port. If an app was talking to multiple things,
would it need to listen on a bunch of different TCP ports. It might be fine
how this all works but I think a little more text is needed.

Section 3.3 

Why invent cmid, couldn't you just reuse mid.

Section 5

Why do you need to discuss character sets such as ISO 8859-1. Seems like
saying UTF-8 would be enough.

<big issue> It looks like the grammar is set up such there is no easy way to
tell if a start-line is a request-line, event-line, or response-line when
parsing. I think this needs to be fixed either by changing the ABNF or
changing the syntax.

Section 5.4
I think line folding is an awful idea, slows down parsers, adds many bugs,
and has no known useful purpose. The fact that other IETF protocols do is
not a known useful purpose.

Allowing both a Header: a,b,c syntax and a multiple Headers of same type was
a bad idea in SIP (see above comment) - I would pick one or the other.

Content-Base: Do you really need to support relative URL at this level? I
understand some specific XML body having a base but can't you just use
absolute URLs at the MRCPv2 level. It's hard to get all the relative stuff
correct particularly when you have ACL based on URL.

Content-Encoding: Add that binary MUST be supported and base64 SHOULD NOT be
used. This is a 8bit safe transport.

Logging-tag - I can't decide if I love this or think it is goofy.

Section 7 - point 2 says basicsynth but I think you called it simplesynth in
section 3.2 

Kill-On-Barge-In - Do you also need some sort of pause-on-barge

When it is a numeric-speech-unit, what is the unit? If undefined, add text
to explain.

page 31 -  Prosody Parameters - do we really need this here if it is also in
SSML.

Page 51 
Waveform-URL: What format. There are tons of various formats I can put in
.wav file - I would rather not use file extensions to figure out formats.

DTMF-Term-Char - I don't get this. This is something like # after typing in
a PIN. This and the DTMF inter digit stuff seem like they should be in the
reco grammar not the MRCP.

Page 57
Can you use a cid URL instead of making up the session URL.

Section 8.8 - if a grammar is compiled, how long is it kept

Section 11 - Is this normative or not. If it conflicts with text which one
is definitive.

Some minor NITS

Lots of formatting issues.

Abstract probably does not need companies that developed MRCPv1.

All the example domain names need to be moved to example.com or such

Section 4 - after defining HX.Y notation, I don't think you use it

Section 6 - bunch of Word got you with " formatting issues.

Section 7 - this would be better drawn as a state machine instead of as a
flow. I am glad to send ASCII art if you want.

Page 32 - top - have SML when I think you mean SSML

Page 34 - "A - value" might be better to say "A negative value"

Page 58 - example 2. Has session URL to local  content but that is not shown
in the example.

Page 59 - reference to NLSML has ref number of 11 but in the bibliography it
is 12.

Section 10
#4 should move to 3261

#8 to #14 have the word " problems

Page 83 - delta-seconds does not seem to be defined

Page 86 numeric-speech-length (and a bunch of others) are redefines of stuff
on page 85

Nice work, Easy to read, Thanks, Cullen

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

---

From: Sarvi Shanmugham <[email-masked]>
Date: Tue, 27 Jan 2004 14:32:44 -0800

asnwers/comments inline.

>When a devices fetches some document, when does it get rid of it.
At least for ASR grammar URI  and TTS content URI that is 
referred/fetched,  The client can specify caching parameters for the 
session and the server is supposed to honor and it decide when to get 
rid of the document from the server cache.

For content that is created/stored on the server as a result of  
commands such as RECORD, is deleted at the end of the session. Note that 
we should also have the option to specify an external URI for recording 
in which case it doesn't get deleted by the server at the end of the 
session and it left to the client to manage.

>and what can be done in both. I don't really like the both solutions.
Most of the SSML parameters such as prosody, etc are available in MRCP 
as headers. but the values specified in SSML take precendence. The MRCP 
header fields allows the client to specify what thedefaultvalues are if 
the SSML document doesn't specify it or if the document is not SSML(say 
plain text).

>No audioplayer definition.
Section 3.2 defines it.
Secition 7.0 describes this. Its essentially a synethsizer that supports 
only the <audio> tag in SSML.

>Doe the user need to be mrcpv2 or is this just an example
I don't understand the question. An MRCPv2 server or client is just a 
SIP UA which also has some additional functionality.

>Section 3.1, example 1, why bother opening a session before getting any
Not required. It was left there to just point out that we could 
"possibly" start with 0 channels and then add from there. But there have 
been too many questions on this. I will remove it from the next version, 
to avoid confusion.

>Section 3.2 - defines  resource type of audioplayer but this is not defined
Well these are synthesizer(Section 7.0) of varying levels of capability 
in their SSML support. I think I should put some forward references to 
Section 7.0 for these resources.

>Why did you pick a port of 9 when the port was unknown. Seems like 0 or
Apparently, thats the NULL port and was recommended for use on the 
alias. Zero was my initial choice, but said to be not the right choice.

>all of this work? Seems like you want the MRCPv2 control channel to open the
This may be a problem for the TCP control channel. Suggestions?

We could allow as an option, for the client to specify the TCP port it 
will be listening to (anything other than port 9), in which case the 
server needs to open the TCP pipe toqwards the client . Any thoughts?

There is also another problem that has been brought to my attention, 
whose solution may be related.  3PCC of resources.

When an MRCPv2 client is setting up a pipe between a resource and 
another endpoint, It may not have the an initial m=audio line to offer, 
may be  because it is a part of a 3pcc setup in progress.
So looks like we need to consider a possibility, where the initial offer 
for an m=audio line may have to come from the server. This might require 
the MRCPv2 client to start with an INVITE to the server with no offer 
and wait for the server to provide the first offer. In this case, we 
need an alternative mechanism of telling the server, what 
resources-types  we need, since we  would not be allowed to  have 
m=control lines in the  INVITE anyway.
I propose that we allow an XML body of some sort containing list of 
resources need, so that  server can make the initial offer with the 
appropriate  m=control lines and m=audio lines in it.

>how this all works but I think a little more text is needed.
The protocol just returns the port to talk to open a TCP pipe. between a 
client and a server, if there is already one or more TCP pipes open, 
they can be shared across multiple MRCP sessions that may be active 
between the two.
section 3.2 and 3.4

>Why invent cmid, couldn't you just reuse mid.
Each m-line can have an mid. But what we are trying to do here is tie 
the m-line with an mid to another m=control line, essentially saying 
this media resource should feed from/to that m=audio line.
I cannot use the mid attribute with the same mid in the m=control line 
that will fail the mid uniqueness criteria.
The option is the group id defined by the same spec as the mid, that 
defines 2 specific group semantics which both don't seem to apply here.
Do you have something else in mind.

>saying UTF-8 would be enough.
I think ISO 8859 is needed for ASR and TTS content for oriental and 
other language support.

>parsing. I think this needs to be fixed either by changing the ABNF or
Not sure what you mean here.
The request line has a method-name and no state
The response has no method name ans a status and a state.
The event has a method name and a state  and no status.
Could you ellaborate.

>a bad idea in SIP (see above comment) - I would pick one or the other.
Need to get back  to you on this.

>correct particularly when you have ACL based on URL.
I think this is an optimization. In VXML documents there is a base URL,  
which needs to be applied for relative URI references that may exist 
within GRXML or SSML documents. The client in many cases does not parse 
through the GRXML or SSML documents to expand such cases before 
providing to the Server.

>used. This is a 8bit safe transport.
fine with me.

>Logging-tag - I can't decide if I love this or think it is goofy.
This is a tag that we added in MRCPv1 and also have in VXML so that logs 
generated by the application server, VXML browser and the media 
processing resources can be corellated.

>Section 7 - point 2 says basicsynth but I think you called it simplesynth in
Will make the correction. I think symplesynth should do.

>Kill-On-Barge-In - Do you also need some sort of pause-on-barge
I haven't heard any request for this so far.  Any thoughts people.

>When it is a numeric-speech-unit, what is the unit? If undefined, add text
Dont' understand.

>page 31 -  Prosody Parameters - do we really need this here if it is also in
To se the default values, if the SSML does not have the prosody or other 
such attributes. Or in cases where the content may not be plain text.

>.wav file - I would rather not use file extensions to figure out formats.
This was initially added for mostly trouble shooting purposes and to 
address the VXMl shadow variable after recognition. This just saves the 
utterance or wave form that was used in the recognition.
I don't mind adding headers to specify formats and such for this recording.

But note, that there is a separate RECORD method that is being proposed 
to do regular recording and stuff that will have mechanisms for the 
client to specify storage location, file formats etc.

>reco grammar not the MRCP.
I think this was added to support VXML with DTMF only support, and the 
VXML spec allows for such things beyond SSML support.

      6.3.3 Generic DTMF Recognizer Properties

of the VXML specification

>Can you use a cid URL instead of making up the session URL.
Well, I thought cid URL was only valid to refer to other parts of a 
single multi-part message.
This is a case, where we have defined grammars with prior methods during 
the session. These get stored
on the server referenced by the Content-ID that came with content.
Now can we really use the cid to refer that content. I thought this was 
not allowed. If thats not the case, I have no problem using cid.

>Section 8.8 - if a grammar is compiled, how long is it kept
Wtih the methods in place, grammars defined using section 8.8 are valid 
for that session. There are requests for managing server level grammars, 
but that has not been addressed yet.

>Section 11 - Is this normative or not. If it conflicts with text which one
Section 11 is definitive. Will try to remove the conflicts as much as 
possible and make it clear this section is definitive.

>Page 86 numeric-speech-length (and a bunch of others) are redefines of stuff

thanks for the comments, I will try to fix them in the next release of 
the spec.

Sarvi