From speechsc-bounces@ietf.org Tue Jun 06 12:51:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnemL-000896-9g; Tue, 06 Jun 2006 12:51:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnemJ-00088w-T7 for speechsc@ietf.org; Tue, 06 Jun 2006 12:51:39 -0400 Received: from web32915.mail.mud.yahoo.com ([68.142.206.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnemH-0000Fu-H1 for speechsc@ietf.org; Tue, 06 Jun 2006 12:51:39 -0400 Received: (qmail 45193 invoked by uid 60001); 6 Jun 2006 16:51:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PspbhjODNHIpPGDTz8HtvNiIJWBdLxFPdfqLK7efPPgOe2IhRIJ4EwISoT0gTqI/MI9/ulV0JazQrS8orD5HrDAhwRCuTuhLxJKyNFnp/myQ03r8ZLsmVifgvPYBIbS/uNaaY9/8CJT4/ANje19p3R/k37Rx8jy5vGQRW5ONWhw= ; Message-ID: <20060606165137.45191.qmail@web32915.mail.mud.yahoo.com> Received: from [66.56.70.131] by web32915.mail.mud.yahoo.com via HTTP; Tue, 06 Jun 2006 09:51:37 PDT Date: Tue, 6 Jun 2006 09:51:37 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] Default support for TLS? To: IETF SPEECHSC In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Tracked at http://www.softarmor.com/roundup/speechsc/ as issue 83. --- "Carter, Jerry" wrote: > I've been trying to understand the origin of the > language in section 12.2: > > > > To ensure control channel protection, MRCPv2 > clients > and servers MUST support TLS and SHOULD utilize > it > by default. Alternative control channel > protection > MAY be used if desired (e.g. IPSEC). > > > > I understand the need for TLS support as a technique > for addressing security > concerns in many environments. TLS is a good thing. > But, I do not > understand why TLS defaults to 'ON'. > > > > Looking back at the minutes from summer 2004 (e.g. > http://www1.ietf.org/mail-archive/web/speechsc/current/msg00888.html > > ) > when TLS was added, I cannot find anyone arguing for > this default value. > Looking at the emails between drafts 6 (where TLS > was not the default) and 7 > (when TLS became the default), I can't find anyone > arguing for this change. > When did the SpeechSC group agree to this? > > > > I am concerned here because the majority of > telephony deployments, the MRCP > server and client are running on the same trusted > network. In many cases, > the cpu & latency costs for performing an > unnecessary encryption step are > desired. For these buyers, using TLS by default is > a barrier for > deployment. > > > > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jun 07 01:54:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqzY-00006k-66; Wed, 07 Jun 2006 01:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqzW-00006d-Dr for speechsc@ietf.org; Wed, 07 Jun 2006 01:54:06 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqzU-0007lf-0L for speechsc@ietf.org; Wed, 07 Jun 2006 01:54:06 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H0062S7MGD8@szxga02-in.huawei.com> for speechsc@ietf.org; Wed, 07 Jun 2006 14:06:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00KJ47MFUC@szxga02-in.huawei.com> for speechsc@ietf.org; Wed, 07 Jun 2006 14:06:16 +0800 (CST) Received: from SANTHANA ([10.18.5.171]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0H00BN47DT30@szxml04-in.huawei.com> for speechsc@ietf.org; Wed, 07 Jun 2006 14:01:06 +0800 (CST) Date: Wed, 07 Jun 2006 11:20:40 +0530 From: santhanakrishnan Subject: [Speechsc] What is the scope of MRCPv2 session To: speechsc@ietf.org Message-id: <000001c689f6$4f2d8060$ab05120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8d68e55b48f2ff3cebd1a6416d9536 Cc: Sarvi@cisco.com X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: santhana@huawei.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0740892559==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0740892559== Content-type: multipart/alternative; boundary="Boundary_(ID_k7AU/pcGaMAtIhDjfWiFmw)" This is a multi-part message in MIME format. --Boundary_(ID_k7AU/pcGaMAtIhDjfWiFmw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The relationship between SIP dialog, MRCP session is not clearly or explicitly stated in the draft. I have given some of the snippets from the "draft-ietf-speechsc-mrcpv2-09" each of which is leading to different interpretations. Even "2.1 Definitions" section does not capture these items. Any amount of clarity would be appreciated. >From page 10. A separate MRCPv2 session is needed to control each of the media processing resources associated with the SIP dialog between the client and server. Within a SIP dialog, the individual resource control channels for the different resources are added or removed through SDP offer/answer carried in a SIP re-INVITE transaction. For each resource there has to be a separate MRCP session? >From page 29 All MRCPv2 requests, responses and events MUST contain the Channel- Identifier header. The value is allocated by the server when a control channel is added to the session and communicated to the client by the "a=channel" atribute in the SDP answer from the server The header value consists of 2 parts separated by the '@' symbol. The first part is an unambiguous string identifying the MRCPv2 session. Please refer to page 163 S->C: SIP/2.0 200 OK To:MediaServer From:sarvi ;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314163 INVITE Contact: Content-Type:application/sdp Content-Length:131 v=0 o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4 s=SDP Seminar i=A session for processing media c=IN IP4 224.2.17.12/127 m=application 32416 TCP/MRCPv2 a=channel:32AECB23433801@speechsynth a=cmid:1 m=audio 48260 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=sendonly a=mid:1 m=application 32416 TCP/MRCPv2 a=channel:32AECB23433802@speechrecog a=cmid:2 m=audio 48260 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=recvonly a=mid:2 Each resource control channel describes a separate session? >From page 54 If the synthesizer and recognizer resources are part of the same MRCPv2 session, they can be optimized for a quicker kill-on-barge-in response if the recognizer and synthesizer interact directly. Multiple resources can there be in a MRCP session? >From page 63 For implementations where a single recognition resource does not support both modes, or simultaneous normal and hotword recognition is desired, the two modes can be invoked through separate resources allocated to the same SIP dialog (with different MRCP session identifiers) and share the RTP audio feed. Can multiple MRCP sessions be there in the same SIP dialog? >From page 8 MRCPv2 uses SIP and SDP to create the client/server dialog and set up the media channels to the server. It also uses SIP and SDP to establish MRCPv2 control sessions between the client and the server for each media processing resource required for that dialog. The MRCPv2 protocol exchange between the client and the media resource is carried on that control session. Again does each resource control channel describe a separate session? Regards, Santhanakrishnan; --Boundary_(ID_k7AU/pcGaMAtIhDjfWiFmw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

            The relationship between SIP dialog, MRCP session is not clearly or explicitly stated in the draft.    

I have given some of the snippets from the “draft-ietf-speechsc-mrcpv2-09” each of which is leading to different interpretations. Even “2.1 Definitions” section does not capture these items. Any amount of clarity would be appreciated.

 

From page 10.

   A separate MRCPv2 session is

   needed to control each of the media processing resources associated

   with the SIP dialog between the client and server.  Within a SIP

   dialog, the individual resource control channels for the different

   resources are added or removed through SDP offer/answer carried in a

   SIP re-INVITE transaction.

For each resource there has to be a separate MRCP session?

 

From page 29

   All MRCPv2 requests, responses and events MUST contain the Channel-

   Identifier header.  The value is allocated by the server when a

   control channel is added to the session and communicated to the

   client by the "a=channel" atribute in the SDP answer from the server

   The header value consists of 2 parts separated by the '@' symbol.

   The first part is an unambiguous string identifying the MRCPv2

   session.

 

   Please refer to page 163

   S->C:

          SIP/2.0 200 OK

          To:MediaServer <sip:mresources@server.example.com>

          From:sarvi <sip:sarvi@example.com>;tag=1928301774

          Call-ID:a84b4c76e66710

          CSeq:314163 INVITE

          Contact:<sip:sarvi@example.com>

          Content-Type:application/sdp

          Content-Length:131

 

          v=0

          o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4

          s=SDP Seminar

          i=A session for processing media

          c=IN IP4 224.2.17.12/127

          m=application 32416  TCP/MRCPv2

          a=channel:32AECB23433801@speechsynth

          a=cmid:1

          m=audio 48260 RTP/AVP 0

          a=rtpmap:0 pcmu/8000

          a=sendonly

          a=mid:1

          m=application 32416  TCP/MRCPv2

          a=channel:32AECB23433802@speechrecog

          a=cmid:2

          m=audio 48260 RTP/AVP 0

          a=rtpmap:0 pcmu/8000

          a=rtpmap:96 telephone-event/8000

          a=fmtp:96 0-15

          a=recvonly

          a=mid:2

Each resource control channel describes a separate session?

 

From page 54

   If the synthesizer and recognizer resources are part of the same

   MRCPv2 session, they can be optimized for a quicker kill-on-barge-in

   response if the recognizer and synthesizer interact directly.

Multiple resources can there be in a MRCP session?

 

From page 63

      For implementations where a single recognition resource does not support

   both modes, or simultaneous normal and hotword recognition is

   desired, the two modes can be invoked through separate resources

   allocated to the same SIP dialog (with different MRCP session

   identifiers) and share the RTP audio feed.

Can multiple MRCP sessions be there in the same SIP dialog?

 

From page 8

   MRCPv2 uses SIP and SDP to create the client/server dialog and set up

   the media channels to the server.  It also uses SIP and SDP to

   establish MRCPv2 control sessions between the client and the server

   for each media processing resource required for that dialog.  The

   MRCPv2 protocol exchange between the client and the media resource is

   carried on that control session.

Again does each resource control channel describe a separate session?

 

Regards,

Santhanakrishnan;

           

--Boundary_(ID_k7AU/pcGaMAtIhDjfWiFmw)-- --===============0740892559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0740892559==-- From speechsc-bounces@ietf.org Wed Jun 07 17:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5UX-000545-PC; Wed, 07 Jun 2006 17:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5UW-00053v-6P for speechsc@ietf.org; Wed, 07 Jun 2006 17:23:04 -0400 Received: from web32915.mail.mud.yahoo.com ([68.142.206.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo5UU-0004qf-PJ for speechsc@ietf.org; Wed, 07 Jun 2006 17:23:04 -0400 Received: (qmail 18842 invoked by uid 60001); 7 Jun 2006 21:23:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lWhH8spK5x+yqBlIjRdf9JmU8ikQRoM0KgtFlK7UlKMQ092WYacI4MPDbxAOhoLON2qdtBOwSEIcmmTSZSGoYIKS90GFf2BKIItAw8E8cx4RbMCbMhrGfMYsYssJrGMYOTIzRpGCSo9hOHE6imksh57hUHo8oA9GcWJmCUEFeQk= ; Message-ID: <20060607212302.18840.qmail@web32915.mail.mud.yahoo.com> Received: from [71.204.33.4] by web32915.mail.mud.yahoo.com via HTTP; Wed, 07 Jun 2006 14:23:02 PDT Date: Wed, 7 Jun 2006 14:23:02 -0700 (PDT) From: Dan Burnett Subject: Re: [Speechsc] Issues around grammar lifetimes To: speechsc@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org This is tracked as issue 84 on http://www.softarmor.com/roundup/speechsc -- Dan Burnett --- "Carter, Jerry" wrote: > Typically, an MRCP client will issue multiple > DEFINE-GRAMMAR messages > eventually followed by a RECOGNIZE. The MRCP client > might reasonably expect > that the defined grammars would be available when > recognition is requested, > but this does not appear to be guaranteed. > Furthermore, I do not see any > notification mechanism for informing the client of > which grammars are > unavailable. > > > > > > There does not appear to be any language in section > 9 that describes grammar > lifetimes. There is language in the session URI > description (section 13.7) > that might relate > > The purpose > of this scheme is to permit access to the > specific resource for > the lifetime of the session with the entity > storing the resource. > > but this is not a normative statement requiring > availability for a session > lifetime. In practice a MRCP server has a finite > cache and may support > multiple parallel sessions. It is unreasonable to > require that the MRCP > server provision a sufficiently large cache to store > all grammars across all > sessions, particularly if sessions are long and > employ large dynamic > grammars. Such a requirement would render small > footprint MRCP servers > impossible. > > If a grammar is flushed from the MRCP server's cache > before RECOGNIZE, the > notification mechanism is unclear. Presumably a > completion cause of > 'grammar-load-failure' would be returned. The > server might want to return a > list of URIs in the message but this would violate > 9.4.12 > > Clients SHOULD NOT interpret the completion > reason text. Instead it > is RECOMMENDED that the reason be recorded in > client logs and > otherwise made available for debugging and > instrumentation purposes. > > and such an approach would need to be standardized. > Additionally, a > developer would like some assurance _before_ > RECOGNIZE is invoked that all > the loaded grammars are available. > > > Because MRCP servers have finite memory and caches, > it is not reasonable to > require that grammars be available on a session > indefinitely after a > DEFINE-GRAMMAR. We might instead require that > grammars have guaranteed > availability on a session only until the next call > to RECOGNIZE; this also > breaks for the same reason. > > > Here is a solution that I believe works. > > (1) An MRCP server SHOULD retain grammars on each > session created by a > DEFINE-GRAMMAR message until at least the next > RECOGNIZE. It MAY retain > grammars for much longer. > > (2) DEFINE-GRAMMAR should support redefining > grammars by passing the IDs > without supplying the grammar definition. The > text/grammar-ref-list media > type might be appropriate for this purpose. > > (3) A RECOGNIZE or a DEFINE-GRAMMAR returning a > completion cause of either > 'grammar-load-failure' or > 'grammar-completion-failure' should include a CRLF > separated list detailing the IDs which grammars did > not load or compile. > > (4) The text in 9.4.11 should support DEFINE-GRAMMAR > returning > 'grammar-load-failure' and > 'grammar-completion-failure'. > > ------------------------- > > Under this proposal, the client might do the > following: > > DEFINE-GRAMMAR documentLevel1 (new definition) > DEFINE-GRAMMAR documentLevel2 (new definition) > DEFINE-GRAMMAR formLevel1 (new definition) > DEFINE-GRAMMAR fieldLevel1 (new definition) > RECOGNIZE > > DEFINE-GRAMMAR documentLevel1 documentLevel2 > formLevel1 (IDs only to > reassert continued need) > DEFINE-GRAMMAR fieldLevel2 (new definition) > RECOGNIZE > > ------------------------- > > Likewise, in the typical error case: > > DEFINE-GRAMMAR documentLevel1 (new definition) > DEFINE-GRAMMAR documentLevel2 (new definition) > DEFINE-GRAMMAR formLevel1 (new definition) > DEFINE-GRAMMAR fieldLevel1 (new definition) > RECOGNIZE > >