Subject: RE: [Speechsc] Comments on draft-ietf-speechsc-mrcpv2-03.txt

From: "Thomas Gal" <[email-masked]>
Date: Mon, 25 Oct 2004 13:36:56 -0700

Comments inline. I never got any comments back on the wording right before
section 2 on page 4:

"It also describes how these messages are carried over a transport layer
such as TCP, SCTP or TLS."

But again I think it should be something like:

"It also describes how these messages are carried over a transport layer
such as TCP or SCTP, and how they can be secured through using TLS."

Just from a perspective of keeping the concepts in line. 

-Tom

[email-masked]  

> Sarvi Shanmugham wrote:
> > Magnus Westerlund wrote:
> >>
> >> 8. Section 2: Do you completely rule out a proxy in MRCPv2? That 
> >> would then be a big difference and should be noted in this 
> section. 
> >> The reason is that it strongly effects if what you have 
> specified in 
> >> terms of methods, signalling will work or not. Also when 
> referencing 
> >> HTTP headers, it is important to consider this issue.
> > 
> > I don't beileve MRCPv2 proxies have been rulled out. If  a proxy 
> > exists, I would expect it to be a back to SIP UA which would also 
> > proxy the
> > MRCPv2 channel messages coming from the client to the appropriate 
> > server behind it.
> >
> 
> Okay, then if I remember correctly, there is some issues with 
> how things are defined. When one has a proxy, one suddenly 
> needs to clarify a lot of things, like:
> - How does the proxy know where to send a request?

Probably you have a farm of MRCP servers that REGISTER their availability
with a registrar that is accessed by the front end proxies to know where to
send requests to. I would assume that most peoples engines already have some
sort of loadbalancing functionality built in anyway so this might be a layer
behind the front end as well.

> - What changes are allowed to the headers and other parts of 
> the requests.

I would suspect none. MRCP is for controlling the media resrouces not for
routing requests right?

> - How do one perform capability detection/negotiation when 
> one have one or more proxies?
> 

No doubt the proxies COULD have varying abilities. Either way they are
really just functioning to pass the requests along in a certain fashion
correct? What specific limiting case are you thinking of?

	Correct me if I'm wrong but these seem like SIP system
implementation issues not MRCP at all. Rather since this is "supposed" to be
protocol agnostic isn't this more of an issue for the protocols used in
setting up the system, as opposed to something we need to address directly?
What strong affects does it have?

> Therefore one can't easily put in proxies, they have to be 
> considered from the beginning. Thus I think that you will 
> have some problem of allowing proxies. I think the WG needs 
> to make a decision if this is desired, and secondly if you 
> are willing to spend the time on doing the work.
> 

	So we need to define what specifically about MRCP begets routing
functionality at this level before we make that decision. What exactly is it
that SIP for example is missing that makes us want to add
functionality(complexity) to MRCP? Obviously there's lots of cases where you
may make SIP decisions based on MRCP headers and such, but again I think
this is more from an infrastructure standpoint and is really just
optimizations, not core MRCP similar to how we were fuddling with combining
enrollment functionality with recognitions. 

> >> Also, what do you mean with dealing with it. They are clearly 
> >> different sources and unless RTP retransmission is used, 
> performing 
> >> speech recognition on different SSRCs are like doing on different 
> >> phone lines in some sense, while in others it is natural 
> to do it on 
> >> the mixed signal from all sources. Further consideration 
> are needed.
> > 
> > It is assumed to be one source. But there may be cases 
> where RFC2833 
> > DTMF packets arrive on the same RTP pipe but with different 
> SSRCs. I 
> > am also not ruling out the case where the server may want 
> to support 
> > recognizing hotwords when listening to a conference. There could be 
> > different speakers on different SSRC in the multicase case and we 
> > might want to respond for anyone saying the "hotword".
> > 
> 
> Okay, I took a look at section 4.3 in version 05. It is a 
> start, however I think you will need a lot of more 
> specification in relation to the media transport. The 
> question is how to handle this, when one has actually learn 
> what is needed. I have to little knowledge about your 
> applications to really help you here. I can compare to RTSP, 
> where it has become evident that we needed to clarify a lot 
> about the handling of RTP. I would recommend you take a look 
> at section B of draft-ietf-mmusic-rfc2326bis-08. I know that 
> this section is not directly applicable, however it may given 
> you some points to think over.
> 
> I would also consider how the negotiation in the SIP domain 
> for media affects the possibility for interoperability.
> 

	I agree that we absolutely should not preclude the ability to send
audio that is the product of mixing a conference to a recognizer with the
understanding that currently this is obviously complicated from the
recognition end as well. Not sure about the details though. Again does this
need to be specified in this document?

> >>
> >> 33. Section 6.1, Cache-Control: So if I understand this correctly, 
> >> this header controls how the media server should cache any 
> resource 
> >> that are referenced in a request to perform a resource 
> purpose, like 
> >> recognition? This is rather different from HTTPs use of 
> the header. 
> >> It might be wise to consider to rename it.
> > 
> > Well the usage of these headers have the same meaning as in HTTP, 
> > except that it is not meant for the reltionship between the MRCP 
> > client and the server, but the HTTP client on the MRCP 
> server and its 
> > cache and its relationship with  the HTTP server where it 
> goes to fetch documents.
> > Which is why these headers have been leveraged from HTTP and their 
> > naming has been left the same.
> > 
> 
> I think that difference is important. In HTTP the 
> cache-control applies to the response, while in MRCPv2 it 
> applies to a referenced resource. I think one should consider 
> renaming the header to avoid misunderstanding.
> 

Absolutely, perhaps something like HTTP-CACHE-CONTROl or
REFERENCE-CACHE-CONTROL. I include the second one because I would guess that
what we are really meaning this for is Incoming cache-control(like
references in an SRGS grammar to another SRGS grammar or a url/text-list
with more URLS etc) as opposed to outgoing (i.e. responses to clients). In
that case I think REFERENCE-CACHE-CONTROL makes more sense because we don't
want to necessarily preclude using other protocols like ftp as well as the
"session:" urls right? Do we literally only mean HTTP URLs? If not perhaps
the wording on this section could be changed a little bit to say that we are
only referring to HTTP for the context of the caching behavior, not in
limiting the protocols that can be used in external references.

> 	b) Another pending issue is the start line format (see 
> attached mail
> 	thread).
> 	  
> 
> This was changed based on early feedback from Cullen gave on 
> this mailing list. The idea was that it was good practice to 
> have the first field recognize the protocol and version. 
> Also, that the Length message be available at a fixed 
> location from the beginning of the message for all messages. 
> It was said that it makes parsing efficient as we know the 
> length of the message by looking at a fixed location from the 
> beginning of the message.
> 
> 

I think this was an absolutely great idea. I feel like most protocols are
like this so that you don't have to wait til some indeterminate point in the
message to know which version parser to send everything to. As well I think
the message length should come early more so you can optimize your network
reads. Wasn't it odd that in the first version it wasn't actually
consistent, and it appeared in different locations based on the type of
request?

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