1 / 4

Speechsc Protocol Proposal

Speechsc Protocol Proposal. http://www.ietf.org/internet-drafts/draft-shanmugham-speechsc-00.txt. Sarvi Shanmugham Cisco Systems Inc. Protocol Summary. Based on MRCP messages for ASR and TTS Control.

maida
Download Presentation

Speechsc Protocol Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Speechsc Protocol Proposal http://www.ietf.org/internet-drafts/draft-shanmugham-speechsc-00.txt Sarvi Shanmugham Cisco Systems Inc.

  2. Protocol Summary • Based on MRCP messages for ASR and TTS Control. • Proposes a SIP based framework with ASR and TTS messaging leveraged from MRCP in the initial draft. Leaves SV and SI as TBD. • Uses SIP/SDP offer/answer model for resource location and session establishment including the setting up of media pipes and a separate speechsc resource control channel. • This control channel is used by the client to control media processing resources such as ASR and TTS engines using messages based on MRCP. • Unlike MRCP the SPEECHSC resource control messages would travel on this separate speechsc control channel over TCP or SCTP and not be tunnelled over RTSP.

  3. Advantages • Leverages the SIP infrastructure in Resource discovery, load balancing, session establishment and session management. • Uses a separate speechsc control to exchange messages with the media processing resources and does not use Tunneling which is considered kludgy. • Suppports TCP/SCTP while current MRCP does not support SCTP. • Does not use UDP for the control channel which would require the speechsc exchange to address transport unreliability. • Allows the sharing of a TCP/SCTP pipe between the client and the server between multiple sessions, which RTSP does not allow. • Leverages the MRCP messages and state machines which is a well proven mechanism for ASR and TTS control. • It is more efficient that RTSP tunneled MRCP in terms of the number of messages exchanged between the client and the server.

  4. Open Protocol Issues • Define SI and SV • Bryan Wyld – Why use SIP when we can add Session management messages to core MRCP and make it an independent protocol. May be Cut/Paste from RTSP. • John Potemri - Client and Server terminology should be consistent and other document edits that are tracked by WG email threads. • Eric Burger – Resource Type and Channel Identifier format. • Neal Deason - Usage of SDP m=control lines to allocate Resource and establish Channel Identifiers • Neal Deason - The use of port 0 not consistent with RFC3264. • Various editorial changes suggested by various folks need to be folded into the next revision of the protocol.

More Related