From speechsc-bounces@ietf.org Tue Jan 02 13:01:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1nwz-00020N-0J; Tue, 02 Jan 2007 13:01:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1nwy-00020I-2n for speechsc@ietf.org; Tue, 02 Jan 2007 13:01:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1nwt-00083n-KR for speechsc@ietf.org; Tue, 02 Jan 2007 13:01:24 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Jan 2007 10:01:19 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l02I1JuV023065; Tue, 2 Jan 2007 10:01:19 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02I1D4g027623; Tue, 2 Jan 2007 10:01:18 -0800 (PST) Received: from [161.44.173.202] (dhcp-161-44-173-202.cisco.com [161.44.173.202]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l02HiVuW011436; Tue, 2 Jan 2007 09:44:31 -0800 In-Reply-To: <001401c72cec$2983b570$ae00a8c0@nsc.co.il> References: <001401c72cec$2983b570$ae00a8c0@nsc.co.il> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Speechsc] Resource Discovery Date: Tue, 2 Jan 2007 13:01:08 -0500 To: ilyak@nscspeech.com X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1686; t=1167760879; x=1168624879; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Speechsc]=20Resource=20Discovery |Sender:=20; bh=HS1PMFnDXuFR5HdV2l67G+YJ+ud7HzG5DxWkWgdsbd4=; b=fq6ieZegeiuCkdCxOjbmWSyhXXEfwT/YhTniLSIDD2kKuIma4FiEmEiLMdW8CEjDr/N+mpST 50U1HxHFsV8Y0Ovzj+AVcuEBKEVAMP8kimkmLFiwZkHYQAOTRLqC+8Ng; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1686; t=1167759871; x=1168623871; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Speechsc]=20Resource=20Discovery |Sender:=20 |To:=20ilyak@nscspeech.com; bh=HS1PMFnDXuFR5HdV2l67G+YJ+ud7HzG5DxWkWgdsbd4=; b=f2hjvp7vTmC0uYJvODnxBJ8U9hFT34kkoamXx8hkWHFkcq/fHjD0N+jeDNUKQSl/x/JlHqTD qKYalaQOnIj9+HkYYoZGLUBpw7Gty7bLZArChrV3GIAI/Smx37Fboosv; Authentication-Results: sj-dkim-1; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: speechsc@ietf.org 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 On Dec 31, 2006, at 9:58 AM, Ilya Knyazhansky wrote: > Hi All > > > > As I understand from reading section 7 of the draft, the =20 > capabilities negotiation can be done using SIP OPTIONS method =96 but =20= > the range of capabilities that can be negotiated this way is rather =20= > limited, how for example the client can learn what languages are =20 > supported by the media processing resource? Or how can the client =20 > discover some performance related characteristics of the resource =20 > (i.e. how much simultaneous calls can be processed by specific =20 > resource). > > > > In SIP, mechanisms like the one defined in RFC3840 exist that allow =20= > more flexible capabilities negotiation but they are not mentioned =20 > in MRCP spec. > > The intention was certainly to allow for RFC3840 capabilities to be =20 used. Perhaps that could be clearer if we included a non-normative =20 reference to this RFC. What is less clear is if we need to register MRCP-specific =20 capabilities to be carried or if the existing registry suffices. In terms of your two examples, the languages supported can be handled =20= with the exisiting accept-language constructs, but the performance-=20 related one s are more problematical because they are highly dynamic. > > > Could you please give more practical, real-life examples on how can =20= > one chose MRCP server based on supported recognition language, =20 > number of supported channels etc > > > > Thanks, > > Ilya > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Wed Jan 03 04:39:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H22aF-0002AZ-7t; Wed, 03 Jan 2007 04:38:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H22aD-0002A3-UI for speechsc@ietf.org; Wed, 03 Jan 2007 04:38:54 -0500 Received: from heller.inter.net.il ([192.114.186.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H22aC-0004Cc-D6 for speechsc@ietf.org; Wed, 03 Jan 2007 04:38:53 -0500 Received: from Elya (natanya.inter.net.il [212.68.144.1] (may be forged)) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id BKZ47069 (AUTH nsc-57); Wed, 3 Jan 2007 11:38:44 +0200 (IST) From: "Ilya Knyazhansky" To: "'David R Oran'" Subject: RE: [Speechsc] Resource Discovery Date: Wed, 3 Jan 2007 11:39:34 +0200 Organization: nsc Message-ID: <004d01c72f1b$14076580$ae00a8c0@nsc.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ilyak@nscspeech.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org Hi All Thanks for clarification, I feel though, that it will be kind of misuse to negotiate language capabilities of a media resource using the Accept-Language header -since it was actually intended to identify languages acceptable in response messages (If MRCP server is configured to return status code reason in German this should not mean that its speech recognizer can understand German language) Thanks, Ilya -----Original Message----- From: David R Oran [mailto:oran@cisco.com] Sent: Tuesday, January 02, 2007 8:01 PM To: ilyak@nscspeech.com Cc: speechsc@ietf.org Subject: Re: [Speechsc] Resource Discovery On Dec 31, 2006, at 9:58 AM, Ilya Knyazhansky wrote: > Hi All > > > > As I understand from reading section 7 of the draft, the > capabilities negotiation can be done using SIP OPTIONS method - but > the range of capabilities that can be negotiated this way is rather > limited, how for example the client can learn what languages are > supported by the media processing resource? Or how can the client > discover some performance related characteristics of the resource > (i.e. how much simultaneous calls can be processed by specific > resource). > > > > In SIP, mechanisms like the one defined in RFC3840 exist that allow > more flexible capabilities negotiation but they are not mentioned > in MRCP spec. > > The intention was certainly to allow for RFC3840 capabilities to be used. Perhaps that could be clearer if we included a non-normative reference to this RFC. What is less clear is if we need to register MRCP-specific capabilities to be carried or if the existing registry suffices. In terms of your two examples, the languages supported can be handled with the exisiting accept-language constructs, but the performance- related one s are more problematical because they are highly dynamic. > > > Could you please give more practical, real-life examples on how can > one chose MRCP server based on supported recognition language, > number of supported channels etc > > > > Thanks, > > Ilya > > > > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www1.ietf.org/mailman/listinfo/speechsc _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From speechsc-bounces@ietf.org Mon Jan 08 01:22:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ntI-0003wF-Hx; Mon, 08 Jan 2007 01:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ntG-0003wA-Dr for speechsc@ietf.org; Mon, 08 Jan 2007 01:21:50 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3ntA-00019G-W9 for speechsc@ietf.org; Mon, 08 Jan 2007 01:21:50 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBJ00AM7DKF78@szxga04-in.huawei.com> for speechsc@ietf.org; Mon, 08 Jan 2007 14:19:28 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBJ00LOCDKEZJ@szxga04-in.huawei.com> for speechsc@ietf.org; Mon, 08 Jan 2007 14:19:27 +0800 (CST) Received: from htiplSASHIDHAR ([10.18.4.185]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBJ005J3DK8O4@szxml03-in.huawei.com> for speechsc@ietf.org; Mon, 08 Jan 2007 14:19:26 +0800 (CST) Date: Mon, 08 Jan 2007 11:49:19 +0530 From: jakki sasidhar To: sarvi@cisco.com, dan_burnett2000@yahoo.com Message-id: <000601c732ec$ef375500$b904120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Accy7O4s8hvS4iZpTFen7YDLhx3Uaw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: speechsc@ietf.org Subject: [Speechsc] Regarding SDP negotiation during session establishment X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jakkis@huawei.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1614852843==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1614852843== Content-type: multipart/alternative; boundary="Boundary_(ID_cngAOnC9QRGLRxPCYUtaDA)" This is a multi-part message in MIME format. --Boundary_(ID_cngAOnC9QRGLRxPCYUtaDA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, In the draft-ietf-speechsc-mrcpv2-11(pg. 15), following is the SDP negotiation during the session establishment. INVITE v=0 o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=application 9 TCP/MRCPv2 a=setup:active a=connection:new a=resource:speechsynth a=cmid:1 m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=recvonly a=mid:1 200 OK v=0 o=- 2890844526 2890842808 IN IP4 126.16.64.4 s=- c=IN IP4 224.2.17.12 m=application 32416 TCP/MRCPv2 a=setup:passive a=connection:new a=channel:32AECB234338@speechsynth a=cmid:1 m=audio 48260 RTP/AVP 00 96 a=rtpmap:0 pcmu/8000 a=sendonly a=mid:1 The following is an example from rfc4145. client m=image 54111 TCP t38 c=IN IP4 192.0.2.2 a=setup:passive a=connection:new server m=image 9 TCP t38 c=IN IP4 192.0.2.1 a=setup:active a=connection:new 1. Here multicast address is used in the connection field, but as we use TCP(unicast) how does this actually work? In the example of rfc4145, it uses unicast addresses of client and server. 2. The SDP in 200 has the same connection address, but how will the client be able to connect to the server without knowing its IP address and only using the port specified in the m-line. 3. Is there ordering that needs to be followed in the control and rtp m-lines? I guess this may be significant when the MRCP client is not the originator of the media. please clarify these.. with regards, Sasidhar --Boundary_(ID_cngAOnC9QRGLRxPCYUtaDA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi,
    In the draft-ietf-speechsc-mrcpv2-11(pg. 15), following is the SDP negotiation during the session establishment.
 
INVITE
          v=0
          o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
          s=-
          c=IN IP4 224.2.17.12
          m=application 9 TCP/MRCPv2
          a=setup:active
          a=connection:new
          a=resource:speechsynth
          a=cmid:1
          m=audio 49170 RTP/AVP 0 96
          a=rtpmap:0 pcmu/8000
          a=recvonly
          a=mid:1
 
200 OK
          v=0
          o=- 2890844526 2890842808 IN IP4 126.16.64.4
          s=-
          c=IN IP4 224.2.17.12
          m=application 32416 TCP/MRCPv2
          a=setup:passive
          a=connection:new
          a=channel:32AECB234338@speechsynth
          a=cmid:1
          m=audio 48260 RTP/AVP 00 96
          a=rtpmap:0 pcmu/8000
          a=sendonly
          a=mid:1
 
The following is an example from rfc4145.
 
client
           m=image 54111 TCP t38
           c=IN IP4 192.0.2.2
           a=setup:passive
           a=connection:new
server
           m=image 9 TCP t38
           c=IN IP4 192.0.2.1
           a=setup:active
           a=connection:new
 
1. Here multicast address is used in the connection field, but as we use TCP(unicast) how does this actually work? In the example of rfc4145, it uses unicast addresses of client and server.
2. The SDP in 200 has the same connection address, but how will the client be able to connect to the server without knowing its IP address and only using the port specified in the m-line.
3. Is there ordering that needs to be followed in the control and rtp m-lines? I guess this may be significant when the MRCP client is not the originator of the media.
 
please clarify these..
 
with regards,
Sasidhar
 
 
--Boundary_(ID_cngAOnC9QRGLRxPCYUtaDA)-- --===============1614852843== 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 --===============1614852843==-- From speechsc-bounces@ietf.org Mon Jan 08 04:41:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3r0h-0001my-Ju; Mon, 08 Jan 2007 04:41:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3r0g-0001ml-RP for speechsc@ietf.org; Mon, 08 Jan 2007 04:41:42 -0500 Received: from [87.198.5.178] (helo=mail.voxpilot.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3r0c-00012m-RV for speechsc@ietf.org; Mon, 08 Jan 2007 04:41:42 -0500 Received: by mail.voxpilot.com (Postfix, from userid 552) id 59C702140FB; Mon, 8 Jan 2007 09:41:29 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on db01ms01 X-Spam-Status: No, score=-3.4 required=5.5 tests=ALL_TRUSTED,AWL,BAYES_00, HTML_MESSAGE autolearn=ham version=3.1.0 X-Spam-Level: Received: from daburkewxp (unknown [10.0.0.102]) by mail.voxpilot.com (Postfix) with ESMTP id 08D9A214042; Mon, 8 Jan 2007 09:41:24 +0000 (GMT) Message-ID: <1cf401c73309$21d97490$6700000a@db01.voxpilot.com> From: "Dave Burke" To: , , References: <000601c732ec$ef375500$b904120a@china.huawei.com> Subject: Re: [Speechsc] Regarding SDP negotiation during session establishment Date: Mon, 8 Jan 2007 09:41:11 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: speechsc@ietf.org 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: , Content-Type: multipart/mixed; boundary="===============1016056026==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1016056026== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1CF1_01C73309.21B4D590" This is a multi-part message in MIME format. ------=_NextPart_000_1CF1_01C73309.21B4D590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sasidhar, Quick comments below with DB>.=20 Dave ----- Original Message -----=20 From: jakki sasidhar=20 To: sarvi@cisco.com ; dan_burnett2000@yahoo.com=20 Cc: speechsc@ietf.org=20 Sent: Monday, January 08, 2007 6:19 AM Subject: [Speechsc] Regarding SDP negotiation during session = establishment Hi, In the draft-ietf-speechsc-mrcpv2-11(pg. 15), following is the SDP = negotiation during the session establishment. INVITE v=3D0 o=3Dsarvi 2890844526 2890842808 IN IP4 126.16.64.4 s=3D- c=3DIN IP4 224.2.17.12 m=3Dapplication 9 TCP/MRCPv2 a=3Dsetup:active a=3Dconnection:new a=3Dresource:speechsynth a=3Dcmid:1 m=3Daudio 49170 RTP/AVP 0 96 a=3Drtpmap:0 pcmu/8000 a=3Drecvonly a=3Dmid:1 200 OK v=3D0 o=3D- 2890844526 2890842808 IN IP4 126.16.64.4 s=3D- c=3DIN IP4 224.2.17.12 m=3Dapplication 32416 TCP/MRCPv2 a=3Dsetup:passive a=3Dconnection:new a=3Dchannel:32AECB234338@speechsynth a=3Dcmid:1 m=3Daudio 48260 RTP/AVP 00 96 a=3Drtpmap:0 pcmu/8000 a=3Dsendonly a=3Dmid:1 The following is an example from rfc4145. client m=3Dimage 54111 TCP t38 c=3DIN IP4 192.0.2.2 a=3Dsetup:passive a=3Dconnection:new server m=3Dimage 9 TCP t38 c=3DIN IP4 192.0.2.1 a=3Dsetup:active a=3Dconnection:new 1. Here multicast address is used in the connection field, but as we = use TCP(unicast) how does this actually work? In the example of rfc4145, = it uses unicast addresses of client and server. DB> Good catch - the intent is of course a unicast address for the = control channel so I believe this is just an editorial error in the = example. 2. The SDP in 200 has the same connection address, but how will the = client be able to connect to the server without knowing its IP address = and only using the port specified in the m-line. DB> This would typically be a different unicast address for the = server. 3. Is there ordering that needs to be followed in the control and rtp = m-lines? I guess this may be significant when the MRCP client is not the = originator of the media. DB> Order for media m-lines follows the usual offer/answer model (RFC = 3264) rules - i.e. order in the offer dictates preference. No such = ordering is defined or indeed necessary for the application m-line = associated with the MRCP control channel.=20 please clarify these.. with regards, Sasidhar -------------------------------------------------------------------------= ----- _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc ------=_NextPart_000_1CF1_01C73309.21B4D590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sasidhar,
 
Quick = comments below=20 with DB>.
 
Dave
----- Original Message -----
From:=20 jakki = sasidhar=20
To: sarvi@cisco.com ; dan_burnett2000@yahoo.com =
Sent: Monday, January 08, 2007 = 6:19=20 AM
Subject: [Speechsc] Regarding = SDP=20 negotiation during session establishment

Hi,
   =20 In the draft-ietf-speechsc-mrcpv2-11(pg. 15), following is = the SDP=20 negotiation during the session establishment.
 
INVITE
       &nbs= p; =20 v=3D0
          = o=3Dsarvi=20 2890844526 2890842808 IN IP4=20 126.16.64.4
         =20 s=3D-
          c=3DIN = IP4=20 224.2.17.12
         =20 m=3Dapplication 9=20 TCP/MRCPv2
         =20 = a=3Dsetup:active
         = ;=20 = a=3Dconnection:new
        &nb= sp;=20 = a=3Dresource:speechsynth
       &nb= sp; =20 a=3Dcmid:1
          = m=3Daudio=20 49170 RTP/AVP 0 = 96
         =20 a=3Drtpmap:0 = pcmu/8000
         =20 a=3Drecvonly
          = a=3Dmid:1
 
200=20 OK
       &nbs= p; =20 v=3D0
          o=3D- = 2890844526=20 2890842808 IN IP4=20 126.16.64.4
         =20 s=3D-
          c=3DIN = IP4=20 224.2.17.12
         =20 m=3Dapplication 32416=20 TCP/MRCPv2
         =20 = a=3Dsetup:passive
        &nbs= p;=20 = a=3Dconnection:new
        &nb= sp;=20 = a=3Dchannel:32AECB234338@speechsynth
     &nb= sp;   =20 a=3Dcmid:1
          = m=3Daudio=20 48260 RTP/AVP 00 = 96
         =20 a=3Drtpmap:0 = pcmu/8000
         =20 a=3Dsendonly
          = a=3Dmid:1
 
The following=20 is an example from rfc4145.
 
client=
       =    =20 m=3Dimage 54111 TCP=20 t38
           = c=3DIN IP4=20 = 192.0.2.2
          = =20 = a=3Dsetup:passive
        &nbs= p; =20 a=3Dconnection:new
server=
       =    =20 m=3Dimage 9 TCP=20 t38
           = c=3DIN IP4=20 = 192.0.2.1
          = =20 = a=3Dsetup:active
         = ; =20 a=3Dconnection:new
 
1. = Here multicast=20 address is used in the connection field, but as we use TCP(unicast) = how does=20 this actually work? In the example of rfc4145, it uses unicast = addresses of=20 client and server.
 
DB> Good catch=20 - the intent is of course a unicast address for the control channel so = I=20 believe this is just an editorial error in the = example.
 
2. = The SDP in 200=20 has the same connection address, but how will the client be able to = connect to=20 the server without knowing its IP address and only using the port = specified in=20 the m-line.
 
DB> This would=20 typically be a different unicast address for the = server.
 
3. = Is there=20 ordering that needs to be followed in the control and rtp = m-lines? I=20 guess this may be significant when the MRCP client is not the = originator of=20 the media.
 
DB> Order for=20 media m-lines follows the usual offer/answer model (RFC 3264) rules - = i.e.=20 order in the offer dictates preference. No such ordering is defined or = indeed=20 necessary for the application m-line associated with the MRCP control = channel.=20
 
please clarify=20 these..
 
with = regards,
Sasidhar
 
 

_______________________________________________
Speechsc = mailing=20 = list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speec= hsc
------=_NextPart_000_1CF1_01C73309.21B4D590-- --===============1016056026== 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 --===============1016056026==-- From speechsc-bounces@ietf.org Mon Jan 08 07:58:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3u4o-0005oK-HV; Mon, 08 Jan 2007 07:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3u4m-0005oB-Nw for speechsc@ietf.org; Mon, 08 Jan 2007 07:58:08 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3u4W-0002J7-Pj for speechsc@ietf.org; Mon, 08 Jan 2007 07:58:08 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBJ000ICVV429@szxga04-in.huawei.com> for speechsc@ietf.org; Mon, 08 Jan 2007 20:54:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JBJ0092AVV33P@szxga04-in.huawei.com> for speechsc@ietf.org; Mon, 08 Jan 2007 20:54:40 +0800 (CST) Received: from prasad1528 ([10.18.4.236]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JBJ0056SVUWTT@szxml04-in.huawei.com> for speechsc@ietf.org; Mon, 08 Jan 2007 20:54:39 +0800 (CST) Date: Mon, 08 Jan 2007 18:24:32 +0530 From: prasadkumbala To: sarvi@cisco.com, dan_burnett2000@yahoo.com Message-id: <001b01c73324$2528ab50$ec04120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcczJCPdLLmczWB7QP+vkpEsm6jdwg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: speechsc@ietf.org Subject: [Speechsc] Query - Record URI ABNF X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prasadkumbala@huawei.com List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749926513==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0749926513== Content-type: multipart/alternative; boundary="Boundary_(ID_xRD7oKb+N/xwAcEhaq0yxg)" This is a multi-part message in MIME format. --Boundary_(ID_xRD7oKb+N/xwAcEhaq0yxg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Accroding to the ABNF for Record Uri record-uri = "Record-URI" ":" [ "<" uri ">" ";" "size" "=" 1*DIGIT ";" "duration" "=" 1*DIGIT]CRLF Size and duration should be mandatorily present in the if uri is present. But when a client is sending RECORD with method Record-URI header what values should be filled by client for size and duration? Example in section 10.6 contradicts with ABNF C->S: MRCP/2.0 386 RECORD 543257 Channel-Identifier:32AECB23433802@recorder Record-URI: Capture-On-Speech:true Final-Silence:300 Max-Time:6000 Thanks in advance, Prasad Kumbala --Boundary_(ID_xRD7oKb+N/xwAcEhaq0yxg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Accroding to the ABNF for Record Uri

   record-uri            =    "Record-URI" ":" [ "<" uri ">"

                           ";" "size" "=" 1*DIGIT

                           ";" "duration" "=" 1*DIGIT]CRLF

  

   Size and duration should be mandatorily present in the if uri is present.

  But when a client is sending RECORD with method Record-URI  header what values should be filled by client for size and duration?

  Example in section 10.6 contradicts with ABNF

C->S:  MRCP/2.0 386 RECORD 543257

          Channel-Identifier:32AECB23433802@recorder

          Record-URI:<file://mediaserver/recordings/myfile.wav>

          Capture-On-Speech:true

          Final-Silence:300

          Max-Time:6000

 

   Thanks in advance,

   Prasad Kumbala

 

 

 

--Boundary_(ID_xRD7oKb+N/xwAcEhaq0yxg)-- --===============0749926513== 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 --===============0749926513==-- From speechsc-bounces@ietf.org Mon Jan 22 05:35:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8wWT-0006qO-J3; Mon, 22 Jan 2007 05:35:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8wWS-0006qJ-O5 for speechsc@ietf.org; Mon, 22 Jan 2007 05:35:32 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8wWR-00083n-6P for speechsc@ietf.org; Mon, 22 Jan 2007 05:35:32 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JC900JX7M4TE9@szxga04-in.huawei.com> for speechsc@ietf.org; Mon, 22 Jan 2007 18:22:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JC900AGZM4SNP@szxga04-in.huawei.com> for speechsc@ietf.org; Mon, 22 Jan 2007 18:22:05 +0800 (CST) Received: from HTIPL20760 ([10.18.4.165]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JC9008SGM4Q16@szxml03-in.huawei.com> for speechsc@ietf.org; Mon, 22 Jan 2007 18:22:04 +0800 (CST) Date: Mon, 22 Jan 2007 15:52:09 +0530 From: sreekanth To: "Saravanan Shanmugham (sarvi)" , Dan Burnett Message-id: <001601c73e0f$2ced01b0$a504120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: speechsc@ietf.org Subject: [Speechsc] Query Regarding the ABNF grammar for Interpret-Text X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sreekanth List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1562918898==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============1562918898== Content-type: multipart/alternative; boundary="Boundary_(ID_lhP3yADuIsre8YfGm0G+aw)" This is a multi-part message in MIME format. --Boundary_(ID_lhP3yADuIsre8YfGm0G+aw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT The section 9.4.30. of draft defines the ABNF for Interpret-Text as interpret-text = "Interpret-Text" ":" 1*VCHAR CRLF But in the example in section 9.20. INTERPRET MRCP/2.0 123 INTERPRET 543266 Channel-Identifier:32AECB23433801@speechrecog Interpret-Text:may I speak to Andre Roy Since VCHAR contains only printable characters, I think the ABNF has to be modified.. Pls clarify on this.. Regards, Sreekanth --Boundary_(ID_lhP3yADuIsre8YfGm0G+aw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
The section  9.4.30. of draft defines the ABNF for Interpret-Text as
 
interpret-text           =  "Interpret-Text" ":" 1*VCHAR CRLF
 
But in the example in section 9.20.  INTERPRET
 
MRCP/2.0 123 INTERPRET 543266
Channel-Identifier:32AECB23433801@speechrecog
Interpret-Text:may I speak to Andre Roy
 
Since VCHAR contains only printable characters, I think the ABNF has to be modified..
 
Pls clarify on this..
 
Regards,
Sreekanth
 
 
 
--Boundary_(ID_lhP3yADuIsre8YfGm0G+aw)-- --===============1562918898== 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 --===============1562918898==--