[1] We could simply treat a conference like a SIP conn= ection=20 and require that the following vxml parameters are filled:

session.connection.local.uri

Evaluates to the value of the conferenceid value

session.connection.remote.uri

Evaluates to the value of the conferenceid value

session.connection.protocol.name

Evaluates to "sip". Note that this is intended to reflect the use of SI= P in=20 general, and does not distinguish between whether the connection accesses t= he MS=20 via SIP or SIPS procedures.

session.connection.protocol.version

Evaluates to "2.0".

where=20 the same values for local.uri and remote.uri would indicate a conference.=20 Simple, but not necessarily true that the conference is a connection entity= .=20

[2] Create an explicit confere= nce=20 object and require that following parameters are set:=20

session.conference.name

Evaluates to the value of the conferenceid value

and=20 then conference media information would go under=20 session.conference.media.

[3] As=20 option [2], but put media stream information in session.media. This is more= =20 aligned with the mediactrl <dialogstart> structure but no longer alig= ned=20 with mediactrl-vxml for the connection's media stream=20 information.

Let me know what you prefer - I'm leaning towards the [2] s= ince it=20 is explicit and compatible with mediactrl-vxml. <= /DIV>

One other issue is that ba= sed on=20 VoiceXML3.0 discussions yesterday, I will change our spec's=20 session.connection.params to session.values (and return it to an associativ= e=20 array) for (potential at least)

alignment. It also makes these parameter values independent of=20 whether the dialog is attached to a connection or conference.=20

thanks

Scott

From: mediactrl-bounces@ietf.org=20 [mailto:mediactrl-bounces@ietf.org] On Behalf Of Stephane=20 Bastien
Sent: Monday, December 01, 2008 16:04
To:=20 mediactrl@ietf.org
Subject: [MEDIACTRL] Comments on Appendix A of= =20 draft-ietf-mediactrl-ivr-control-package-03

Hi,<= /P>

Thank you for introducing App= endix A=20 into the ivr-control-package draft =96 it will make interoperability with V= oiceXML=20 scripts a lot easier. I have a few comments:

Section 12.2.1 Session protoc= ol=20 information: when using <dialogstart> with a conferenceid, what are t= he=20 recommended values for session.connection.* ?

Section 12.5 Call Transfer: T= he MS=20 should throw to the VoiceXML script error.unsupported.transfer.blind or=20 error.unsupported.transfer.bridge, as defined in VoiceXML 2.0, instead of=20 terminating the dialog. This would be in-line with existing VoiceXML error= =20 handling.

Thanks,

St=E9phane=

<= /HTML> --_000_DFD8836B64F74B489D48B163BFE9D55447EB944B77GVW1124EXCame_-- --===============1617779213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl --===============1617779213==-- From mediactrl-bounces@ietf.org Thu Dec 4 07:12:08 2008 Return-Path: X-Original-To: mediactrl-archive@optimus.ietf.org Delivered-To: ietfarch-mediactrl-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42923A6B07; Thu, 4 Dec 2008 07:12:08 -0800 (PST) X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F52C3A6AF9 for ; Thu, 4 Dec 2008 07:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O35B03tDrLQg for ; Thu, 4 Dec 2008 07:12:03 -0800 (PST) Received: from ATL1VEXC020.usdom003.tco.tc (atl1vexc020.usdom003.tco.tc [209.225.56.95]) by core3.amsl.com (Postfix) with ESMTP id D57BD3A6B07 for ; Thu, 4 Dec 2008 07:12:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Dec 2008 10:12:00 -0500 Message-ID: <0D180B9E33C55148A2FA69A7CF0617C001F6CE28@ATL1VEXC020.usdom003.tco.tc> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Appendix A ofdraft-ietf-mediactrl-ivr-control-package-03 Thread-Index: AclTxfxJQ02MYjqCRTmkpSb5I8cktQAAFWEAAJUzzxA= References: <0D180B9E33C55148A2FA69A7CF0617C001EDFCFB@ATL1VEXC020.usdom003.tco.tc> From: "Stephane Bastien" To: "McGlashan, Scott" , Subject: Re: [MEDIACTRL] Comments on Appendix A ofdraft-ietf-mediactrl-ivr-control-package-03 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1596162874==" Sender: mediactrl-bounces@ietf.org Errors-To: mediactrl-bounces@ietf.org This is a multi-part message in MIME format. --===============1596162874== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95622.A81D1C84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95622.A81D1C84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These are all good proposals. Option #2 looks a little cleaner, but this = is just a preference. =20 ________________________________ From: McGlashan, Scott [mailto:scott.mcglashan@hp.com]=20 Sent: 3 d=E9cembre 2008 11:08 To: Stephane Bastien; mediactrl@ietf.org Subject: RE: Comments on Appendix A = ofdraft-ietf-mediactrl-ivr-control-package-03 =20 (...) =20 [1] We could simply treat a conference like a SIP connection and = require that the following vxml parameters are filled: =20 session.connection.local.uri Evaluates to the value of the conferenceid value session.connection.remote.uri Evaluates to the value of the conferenceid value session.connection.protocol.name Evaluates to "sip". Note that this is intended to reflect the use of SIP = in general, and does not distinguish between whether the connection = accesses the MS via SIP or SIPS procedures.=20 session.connection.protocol.version Evaluates to "2.0".=20 =20 where the same values for local.uri and remote.uri would indicate a = conference. Simple, but not necessarily true that the conference is a = connection entity.=20 =20 =20 [2] Create an explicit conference object and require that following = parameters are set:=20 =20 session.conference.name=20 Evaluates to the value of the conferenceid value =20 and then conference media information would go under = session.conference.media. =20 [3] As option [2], but put media stream information in session.media. = This is more aligned with the mediactrl structure but no = longer aligned with mediactrl-vxml for the connection's media stream = information. =20 Let me know what you prefer - I'm leaning towards the [2] since it is = explicit and compatible with mediactrl-vxml.=20 =20 =20 ------_=_NextPart_001_01C95622.A81D1C84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

These are all good proposals. = Option #2 looks a little cleaner, but this is just a = preference.

From: = McGlashan, Scott [mailto:scott.mcglashan@hp.com]
Sent: 3 d=E9cembre 2008 = 11:08
To: Stephane Bastien; mediactrl@ietf.org
Subject: RE: Comments on = Appendix A = ofdraft-ietf-mediactrl-ivr-control-package-03

(…)

[1] We could simply treat a = conference like a SIP connection and require that the following vxml parameters are filled:

session.connection.local.uri

Evaluates to = the value of the conferenceid value

session.connection.remote.uri

Evaluates to = the value of the conferenceid value

session.connection.protocol.name

Evaluates to "sip". Note that this is intended to reflect the use of SIP in general, and does not distinguish between whether the connection = accesses the MS via SIP or SIPS procedures.

session.connection.protocol.version

Evaluates to "2.0".

where the same values for local.uri = and remote.uri would indicate a conference. Simple, but not necessarily true = that the conference is a connection entity.

[2] Create an = explicit conference object and require = that following parameters are set: =

session.conference.name

Evaluates to = the value of the conferenceid value

and then conference media = information would go under session.conference.media.

[3] As option [2], but put media = stream information in session.media. This is more aligned with the mediactrl <dialogstart> structure but no longer aligned with mediactrl-vxml = for the connection's media stream information.

Let me know what you prefer - I'm = leaning towards the [2] since it is explicit and compatible with = mediactrl-vxml.

------_=_NextPart_001_01C95622.A81D1C84-- --===============1596162874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl --===============1596162874==-- From mediactrl-bounces@ietf.org Thu Dec 11 13:33:25 2008 Return-Path: X-Original-To: mediactrl-archive@optimus.ietf.org Delivered-To: ietfarch-mediactrl-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD993A67F1; Thu, 11 Dec 2008 13:33:25 -0800 (PST) X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AED3A67F1 for ; Thu, 11 Dec 2008 13:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4ne691Hp3kx for ; Thu, 11 Dec 2008 13:33:23 -0800 (PST) Received: from bdsoft10.vwh.net (bdsoft10.vwh.net [130.94.149.229]) by core3.amsl.com (Postfix) with ESMTP id 66FE93A679F for ; Thu, 11 Dec 2008 13:33:23 -0800 (PST) Received: from [192.168.8.44] ([208.48.227.7]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6.20060614/8.13.6) with ESMTP id mBBLXBwu038532 for ; Thu, 11 Dec 2008 16:33:16 -0500 (EST) From: =?ISO-8859-1?Q?Jean-Fran=E7ois?= Bertrand To: mediactrl@ietf.org Date: Thu, 11 Dec 2008 16:33:11 -0500 Message-Id: <1229031191.31663.19.camel@meije> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Subject: [MEDIACTRL] msc-ivr.xsd validation failure with xerces-c 3.0 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1358442936==" Sender: mediactrl-bounces@ietf.org Errors-To: mediactrl-bounces@ietf.org --===============1358442936== Content-Type: multipart/alternative; boundary="=-s4l86pfQoYIMCb3sdEyw" --=-s4l86pfQoYIMCb3sdEyw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit The formal syntax proposed in draft-ietf-mediactrl-ivr-control-package-03 appears to be invalid due to an error in the extensible core type. Xerces-c 3.0 is unable to use the proposed schema to validate msc-ivr/1.0 messages. Xerces-c fails with the following error: "complex type 'parType' violates the unique particle attribution rule in its components '##other' and '##other'" As a workaround, I ended up commenting up part of the Tcore complexType definition as follow: This type is extended by other component types to allow elements and attributes from other namespaces to be added. Jean-François Bertrand, ing. Sr. Software Designer BroadSoft, Inc. Montreal, Qc, Canada --=-s4l86pfQoYIMCb3sdEyw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit The formal syntax proposed in draft-ietf-mediactrl-ivr-control-package-03 appears to be invalid due to an error in the extensible core type. Xerces-c 3.0 is unable to use the proposed schema to validate msc-ivr/1.0 messages. Xerces-c fails with the following error:

   "complex type 'parType' violates the unique particle attribution rule in its components '##other' and '##other'"

As a workaround, I ended up commenting up part of the Tcore complexType definition as follow:

<xsd:complexType name="Tcore">
<xsd:annotation>
   <xsd:documentation>
    This type is extended by other component types to
    allow elements and attributes from other namespaces
    to be added.
   </xsd:documentation>
</xsd:annotation>
<xsd:sequence>

</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>

Jean-François Bertrand, ing.
Sr. Software Designer
BroadSoft, Inc.
Montreal, Qc, Canada

--=-s4l86pfQoYIMCb3sdEyw-- --===============1358442936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl --===============1358442936==-- From mediactrl-bounces@ietf.org Thu Dec 11 16:50:38 2008 Return-Path: X-Original-To: mediactrl-archive@optimus.ietf.org Delivered-To: ietfarch-mediactrl-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C64A3A686D; Thu, 11 Dec 2008 16:50:38 -0800 (PST) X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249163A686D for ; Thu, 11 Dec 2008 16:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvSaY2iGD2TX for ; Thu, 11 Dec 2008 16:50:31 -0800 (PST) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by core3.amsl.com (Postfix) with ESMTP id 691F13A67EA for ; Thu, 11 Dec 2008 16:50:31 -0800 (PST) Received: from ppp118-208-209-12.lns10.mel6.internode.on.net (HELO [192.168.0.5]) ([118.208.209.12]) by ipmail04.adl2.internode.on.net with ESMTP; 12 Dec 2008 11:19:06 +1030 Message-ID: <4941B4FF.40107@nteczone.com> Date: Fri, 12 Dec 2008 11:49:03 +1100 From: Christian Groves User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: mediactrl@ietf.org Subject: [MEDIACTRL] draft-ietf-mediactrl-ivr-control-package-03 and X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mediactrl-bounces@ietf.org Errors-To: mediactrl-bounces@ietf.org Hello, I'm having a look at the element in section 4.3.1.2. of the IVR draft. Towards the end of the section it describes the interactions between the different keys. Several sets of interactions do not seem to be explicitely described, what happens when playback is paused and keys other than "resume" are pressed? There is a text: 2. Runtime controls are active only during prompt playback (if no element is specified, then runtime controls are ignored). Does this mean that key presses other than resume are ignored? Or is the correct behaviour that the key press action is applied? ie. During pause if fast forward is pressed playout will commence at the skip interval past the pause point During pause if volume up is pressed will the volume increase X percent when the resume key is pressed? or does playback start automatically with a volume increase of X percent? On a side point I assume that there should also be text regarding what happens when the speed operations go beyond what is supported. Regards, Christian _______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl From mediactrl-bounces@ietf.org Fri Dec 19 03:45:57 2008 Return-Path: X-Original-To: mediactrl-archive@optimus.ietf.org Delivered-To: ietfarch-mediactrl-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444563A68DF; Fri, 19 Dec 2008 03:45:57 -0800 (PST) X-Original-To: mediactrl@core3.amsl.com Delivered-To: mediactrl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040003A68DF for ; Fri, 19 Dec 2008 03:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.269 X-Spam-Level: X-Spam-Status: No, score=-106.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3sRSoG3LtUo for ; Fri, 19 Dec 2008 03:45:55 -0800 (PST) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id 242103A687F for ; Fri, 19 Dec 2008 03:45:55 -0800 (PST) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id 26D2630386; Fri, 19 Dec 2008 11:45:42 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.1.263.0; Fri, 19 Dec 2008 11:43:53 +0000 Received: from GVW1124EXC.americas.hpqcorp.net ([16.228.24.50]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Fri, 19 Dec 2008 11:43:53 +0000 From: "McGlashan, Scott" To: =?iso-8859-1?Q?Jean-Fran=E7ois_Bertrand?= , "mediactrl@ietf.org" Date: Fri, 19 Dec 2008 11:43:52 +0000 Thread-Topic: [MEDIACTRL] msc-ivr.xsd validation failure with xerces-c 3.0 Thread-Index: Aclb2Ba5nf2ynFiHQqKruze87Ts03wF9ZwmX Message-ID: References: <1229031191.31663.19.camel@meije> In-Reply-To: <1229031191.31663.19.camel@meije> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [MEDIACTRL] msc-ivr.xsd validation failure with xerces-c 3.0 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mediactrl-bounces@ietf.org Errors-To: mediactrl-bounces@ietf.org Sorry for the delay in replying. I'm a bit puzzled about this one - the extensible core type is used in almo= st every element definition so why the xml processor only complains about p= arType is a bit strange (it should have encountered the same problem with <= mscivr>,