Subject: [Speechsc] Agenda for Speechsc

From: "Eric Burger" <[email-masked]>
Date: Mon, 17 Mar 2003 19:06:49 -0500

TUESDAY, March 18, 2003
1415-1515 Afternoon Sessions II
Continental 7 TSV speechsc Speech Services Control WG 

Note Well and Agenda Bashing   5 min
Requirements Status            5 min
Protocol Analysis Status      20 min
Document Assignments          10 min
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Brian Wyld" <[email-masked]>
Date: Tue, 18 Mar 2003 09:14:44 +0100

Hi Eric,

Although I cannot be there at the IETF meeting (sob), I have come across a
requirement for speechsc that I am not sure is covered in the requirements
doc..... (and yes, I know its late to throw in new
requirements.....sorry...)

The issue is "legal/commercial" rather than technical, but nontheless real
:-<

Problem
-------
Basically, the issue is that several ASR motor vendors require to be able to
identify the "call context" for the recognise requests, as they either
require all recognise requests for the same call to use exclusively the same
"port" (==RTSP/RTP session when using MRCP) or have discount levels
depending on the number of requests associated to the same call, or both(!).

MRCP is lacking in this department, as it has no clear mapping between a
call and an MRCP request. One might assume a 1:1 mapping between the RTSP
SETUP/TEARDOWN and call start/end, but in fact :
 - some mrcp clients do a SETUP/TEARDOWN per MRCP transaction
 - some mrcp clients do a SETUP at the platform bringup and TEARDOWN at
shutdown (possible with clients that can re-route the RTP stream dynamically
to different trunks for instance)

Although one could just tighten this up by stating 'the RTSP session
start/end MUST corrospond to the call start/end, and all MRCP requests
relating to the same call MUST use the same RTSP session', I think this is
far too restrictive, as there may be significant performance benefits to
keeping the RTSP session open for platform lifetime, as well as other
"provisioning/monitoring" benefits (if the platform provisions its RTP media
channels at startup, and can monitor their state, it can be sure of the
exact level of available resources at all times - important for telephony
systems)

In the case of MRCP therefore, I would suggest we need a new pair of MRCP
level messages:
CALL_CONTEXT_BEGIN
 - signal start of a "call"
 - defines a "callId", unique for the RTSP session on which it is sent
CALL_CONTEXT_END
 - signal end of the "call" for this RTSP session
plus to add the callId in a suitable header to the MRCP RECOGNISE and SPEAK
messages eg
CallId : <callId>

Server vendors would then be free to reject resource requests on the same
RTSP/RTP channel that had overlapping callIds if they had a legal/commercial
need, or just ignore these new messages/header if they do not (this would
anyway be the default behaviour for an existing MRCP implementation I would
hope - be liberal in what you accept eh?)

I don't know if you could throw this into the discussion, or maybe its
already covered in the requirements doc and I'm just not reading it
right.....

Anyway, enjoy!

Brian

[Brian Wyld] [[email-masked]]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part
> de Eric Burger
> Envoyé : Tuesday, March 18, 2003 01:07
> À : IETF SPEECHSC (E-mail)
> Cc : [email-masked]
> Objet : [Speechsc] Agenda for Speechsc
>
>
> TUESDAY, March 18, 2003

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 21 Mar 2003 21:10:28 -0800

I am not sure if this is what you are looking for.
But MRCP has 2 mechanisms aimed towards this problem.

1. There is a channel-Reset header field that can be sent. This allows 
the client to tell the recognizer to drop the line quality and other 
voice quality information it has learned for the current voice session 
and resets this information. This was placed for the purpose of using a 
single open MRCP session for more than one call one after the other.

2. When you close an MRCP recognizer session, the recognizer could 
return a Context-Block of data (treated as an opaque block of data) back 
to the client. The client is required to send pass that block of opaque 
data to the next server in the SETUP message(if the new session is a 
continuation of the call).

Does this cover your needs. If so, then the requirement is already 
covered since the SpeechSC refers to MRCP as the model for requirements.

Sarvi

---

From: "Brian Wyld" <[email-masked]>
Date: Wed, 26 Mar 2003 22:07:18 +0100

Hi Sarvi,

I don't think either of these mechanisms covers the requirement.

1/ they are somewhat obscure - the need is for a specific mapping between
the MRCP transactions and a call start/end identification.

2/ the channel reset allows the idea that the SETUP/TEARDOWN does not match
to the call start/end, but does not help in matching requests to calls

3/ the Context-Block from the server is passed back in the next SETUP - so
if the client wishes to have a single SETUP spanning multiple calls this
does not help. Also, the need is for the client to notify the server of the
call delimitations, rather than the server mapping SETUPs to calls....

I think there is a need for a specific requirement for instance:
"The speechsc protocol MUST provide a means for the client to assign an
identifier to a call session, and to communicate this to the speechsc server
as being associated with a particular media session. The speechsc protocol
MUST provide a means to associate all  requests (ie ASR/TTS/SV/SI operation
requests) to a specific call session id. "

This information would not change the functional operation of the protocol;
the server would then be free to either ignore this information, use it for
billing, or use it to enforce a particular legal license mapping (eg
start-call for a specific media session means that only requests with the
same id are accepted on that session until the end-call releases it.)

Brian

  -----Message d'origine-----
  De : Sarvi Shanmugham [mailto:[email-masked]]
  Envoyé : Saturday, March 22, 2003 06:10
  À : [email-masked]
  Cc : 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
  Objet : Re: [Speechsc] Agenda for Speechsc

  1. There is a channel-Reset header field that can be sent. This allows the
client to tell the recognizer to drop the line quality and other voice
quality information it has learned for the current voice session and resets
this information. This was placed for the purpose of using a single open
MRCP session for more than one call one after the other.

  2. When you close an MRCP recognizer session, the recognizer could return
a Context-Block of data (treated as an opaque block of data) back to the
client. The client is required to send pass that block of opaque data to the
next server in the SETUP message(if the new session is a continuation of the
call).

  Does this cover your needs. If so, then the requirement is already covered
since the SpeechSC refers to MRCP as the model for requirements.

  Sarvi

  Brian Wyld wrote:

Hi Eric,

Problem
-------

Anyway, enjoy!

Brian

-----Message d'origine-----

TUESDAY, March 18, 2003

---

From: Sarvi Shanmugham <[email-masked]>
Date: Fri, 28 Mar 2003 00:27:07 -0800

I am confused with you requirements.

I am not saying that the MRCP headers are aclean way of solving your 
problem. But I think they DO solve your exact problems. So I was just 
pointing out that this requirement is covered SPEECHSC through its 
reference to MRCP.

Now in the SPEECHSC protocol, whether we use the MRCP mechanism to solve 
this requirment or not is a separate issue.

Now coming to your comments below.

Brian Wyld wrote:

> 1/ they are somewhat obscure - the need is for a specific mapping 
> between the MRCP transactions and a call start/end identification.
>  

In general an MRCP session is associated with a single call.  Now if we 
choose to reuse a single MRCP session to multiple subsequent calls, 
thats where the Channel-Reset-Header comes into play.
This ofcourse assumes that during the course of a call there is an MRCP 
session assoiated with that call, and that MRCP session will not be used 
for other calls. This covers 1 & 2 here.

> 2/ the channel reset allows the idea that the SETUP/TEARDOWN does not 
> match to the call start/end, but does not help in matching requests to 
> calls
>  
> 3/ the Context-Block from the server is passed back in the next SETUP 
> - so if the client wishes to have a single SETUP spanning multiple 
> calls this does not help. Also, the need is for the client to notify 
> the server of the call delimitations, rather than the server mapping 
> SETUPs to calls....

My reason for 3 is that this helps when you are switching between one 
media server and another, and we know the call is the same and hence the 
audio pipe is the same(just the audio, not the ports).

> "The speechsc protocol MUST provide a means for the client to assign 
> an identifier to a call session, and to communicate this to the 
> speechsc server as being associated with a particular media 
> session. The speechsc protocol MUST provide a means to associate all 
> requests (ie ASR/TTS/SV/SI operation requests) to a specific call 
> session id. "
>  
> This information would not change the functional operation of the 
> protocol; the server would then be free to either ignore this 
> information, use it for billing, or use it to enforce a particular 
> legal license mapping (eg start-call for a specific media session 
> means that only requests with the same id are accepted on that session 
> until the end-call releases it.)

We do have a Session-ID that can be used for billing and stuff. And the 
requirements for call association, which are primarily to learn audio 
line charactersitcs of the call for better performance is covered by the 
Context block and Channel-Reset headers.

We can always design a cleaner approach in SpeechSC that these to 
methods used in MRCP.

I am just avoiding having to make changes to SpeechSC requirements which 
is in a relative state of completion, and mainly because I see your 
requirements as already covered by reference to MRCP.

Sarvi

---

From: "Brian Wyld" <[email-masked]>
Date: Fri, 28 Mar 2003 13:22:14 +0100

Hi Sarvi,

Ok, I see your point. However, I still think it would be better to have an
explicit requirement as the use cases of the MRCP header are not very clear.

I'm perhaps also confused as to the term "MRCP session".

I see an RTSP session (ie SETUP/TEARDOWN) which is related to the media, but
this RTSP session can be used sequentially by multiple different MRCP
transactions. The Channel-Reset-Header allows the client to ensure that the
media session is "clean" for its MRCP transaction, but offers no indication
to the server as to the relationship between MRCP transactions.

Between two MRCP RECOGNISE requests, I guess I don't see any way to
associate them (whether on the same RTSP session or on different ones)?

Brian

  -----Message d'origine-----
  De : Sarvi Shanmugham [mailto:[email-masked]]
  Envoye : Friday, March 28, 2003 09:27
  A : [email-masked]
  Cc : 'Eric Burger'; 'IETF SPEECHSC (E-mail)'
  Objet : Re: [Speechsc] Agenda for Speechsc

  I am not saying that the MRCP headers are aclean way of solving your
problem. But I think they DO solve your exact problems. So I was just
pointing out that this requirement is covered SPEECHSC through its reference
to MRCP.

  Brian Wyld wrote:

    Hi Sarvi,

  In general an MRCP session is associated with a single call.  Now if we
choose to reuse a single MRCP session to multiple subsequent calls, thats
where the Channel-Reset-Header comes into play.
  This ofcourse assumes that during the course of a call there is an MRCP
session assoiated with that call, and that MRCP session will not be used for
other calls. This covers 1 & 2 here.

    2/ the channel reset allows the idea that the SETUP/TEARDOWN does not
match to the call start/end, but does not help in matching requests to calls

    3/ the Context-Block from the server is passed back in the next SETUP -
so if the client wishes to have a single SETUP spanning multiple calls this
does not help. Also, the need is for the client to notify the server of the
call delimitations, rather than the server mapping SETUPs to calls....
  My reason for 3 is that this helps when you are switching between one
media server and another, and we know the call is the same and hence the
audio pipe is the same(just the audio, not the ports).

    This information would not change the functional operation of the
protocol; the server would then be free to either ignore this information,
use it for billing, or use it to enforce a particular legal license mapping
(eg start-call for a specific media session means that only requests with
the same id are accepted on that session until the end-call releases it.)
  We do have a Session-ID that can be used for billing and stuff. And the
requirements for call association, which are primarily to learn audio line
charactersitcs of the call for better performance is covered by the Context
block and Channel-Reset headers.

  We can always design a cleaner approach in SpeechSC that these to methods
used in MRCP.

  Sarvi

    Brian