Re: [MEDIACTRL] Clarifications concerning the repeatUntilComplete attribute

"McGlashan, Scott" <scott.mcglashan@hp.com> Sat, 02 October 2010 16:16 UTC

Return-Path: <scott.mcglashan@hp.com>
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 0BC873A6CD9 for <mediactrl@core3.amsl.com>; Sat, 2 Oct 2010 09:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.099
X-Spam-Level:
X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, 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 i0WVTcpGOl+b for <mediactrl@core3.amsl.com>; Sat, 2 Oct 2010 09:16:00 -0700 (PDT)
Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by core3.amsl.com (Postfix) with ESMTP id E5F473A6E87 for <mediactrl@ietf.org>; Sat, 2 Oct 2010 09:15:59 -0700 (PDT)
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 g6t0187.atlanta.hp.com (Postfix) with ESMTPS id 63EA52831A; Sat, 2 Oct 2010 16:16:49 +0000 (UTC)
Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 2 Oct 2010 16:12:55 +0000
Received: from GVW1124EXC.americas.hpqcorp.net ([16.228.24.184]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Sat, 2 Oct 2010 16:12:55 +0000
From: "McGlashan, Scott" <scott.mcglashan@hp.com>
To: Jean-Francois Bertrand <jeffy@broadsoft.com>, "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Sat, 2 Oct 2010 16:12:50 +0000
Thread-Topic: [MEDIACTRL] Clarifications concerning the repeatUntilComplete attribute
Thread-Index: ActiTKubMMGzR8rSTLW6gZAppkAXqQ==
Message-ID: <C8CD2334.8FB9%Scott.McGlashan@hp.com>
In-Reply-To: <D64134C7765B58448BEF1C5E0B4BBB1514AB685AEF@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.0.0.100802
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MEDIACTRL] Clarifications concerning the repeatUntilComplete attribute
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Oct 2010 16:16:04 -0000

Hi Jean-Francois,


1.       By “A value of false indicates that dialog execution is terminated by other means”, is it meant that the dialog waits for a <dialogterminate> or for the user to hangup before sending its <dialogexit>?


[scott] This is defined in the dialog execution model – see especially step 5 in Section 4.3.1. So not just AS or user termination,  but any termination status from collect or record execution.


2.       what should be the behaviour if repeatUntilComplete is not present? (risk of resource leak)


[scott] It defaults to false  - so the behavior depends on the value of the other dialog attributes repeatCount and repeatDur. In the case, where repeatDur is not present and repeatCount = 1, then dialog exits when the prompt/collect/record elements terminate  - and that include the cases where record timeouts and no DTMF is collected.



3.       Shouldn’t the default value of repeatUntilComplete be true?


[scott] repeatUntilComplete was seen as an advanced feature  and hence the AS has to explicitly activate it by setting the value to true. Setting the default to false means that the AS by default gets a report back from the MS whenever the prompt/collect/record operation is done – whether collect or recording was successful or not. It can then decide whether to reprompt or not, or take another behavior.


Let me know if there is something that needs to be clarified in the specification since we're finalizing it now.


Thanks


Scott



From: Jean-Francois Bertrand <jeffy@broadsoft.com<mailto:jeffy@broadsoft.com>>
Date: Wed, 18 Aug 2010 15:15:50 +0000
To: "mediactrl@ietf.org<mailto:mediactrl@ietf.org>" <mediactrl@ietf.org<mailto:mediactrl@ietf.org>>
Subject: [MEDIACTRL] Clarifications concerning the repeatUntilComplete attribute

I have the following questions concerning the behaviour to adopt with the repeatUntilComplete attribute:

1.       By “A value of false indicates that dialog execution is terminated by other means”, is it meant that the dialog waits for a <dialogterminate> or for the user to hangup before sending its <dialogexit>?

2.       what should be the behaviour if repeatUntilComplete is not present? (risk of resource leak)

3.       Shouldn’t the default value of repeatUntilComplete be true?


The repeatUntilComplete attribute is defined like this:


        “indicates whether the MS terminates dialog

      execution when an input operation is completed successfully.  A

      valid value is a boolean (see Section 4.6.1<http://tools.ietf.org/html/draft-ietf-mediactrl-ivr-control-package-08#section-4.6.1>)1>).  A value of true

      indicates that dialog execution is terminated when an input

      operation associated with its child elements is completed

      sucessfully (see execution model below for precise conditions).  A

      value of false indicates that dialog execution is terminated by

      other means.  The attribute is optional.  The default value is

      false.”

Scenarios where repeatUntilComplete is true are pretty clear.  The server sends a <dialogexit> upon completion, completion being defined as something recorded or something collected.  One question though: why isn’t true the default value of repeatUntilComplete?  If one forget to specify repeatUntilComplete, a default value of false is used which could easily leads to resource leak.

When repeatUntilComplete is false, I am a bit confused about the “other means” meaning.  How does a record dialog like this terminate:

<dialog repeatCount=”1” repeatUntilComplete=”false”><record/></dialog>

Assuming it filled its record buffer, what does it do upon its default 15sec expiration?   Should the dialog terminate and send its <dialogexit> ?  Or should it wait for a <dialogterminate> or for the user to hangup before sending its <dialogexit>?

If, in the example above, repeatCount is set to 3, is it correct to assume that the dialog saves 3 recordings and sends a <dialogexit>?  Or does it simply save 3 recording and wait for a <dialogterminate>/userHangup before sending its <dialogexit>?

What is the proper behaviour when collecting digits with repeatUntilCompleteset to false?  When collecting digits and recording with repeatUntilComplete set to false?  When playing file only?

Thanks a lot for clarifying these scenarios.

Jean-François Bertrand
Sr. Software Designer | BroadSoft, Inc.