[MEDIACTRL] Clarifications concerning the repeatUntilComplete attribute

Jean-Francois Bertrand <jeffy@broadsoft.com> Wed, 18 August 2010 15:15 UTC

Return-Path: <jeffy@broadsoft.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 3E4873A6944 for <mediactrl@core3.amsl.com>; Wed, 18 Aug 2010 08:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
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 RxQ9Cy8qX0ub for <mediactrl@core3.amsl.com>; Wed, 18 Aug 2010 08:15:21 -0700 (PDT)
Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 461043A6848 for <mediactrl@ietf.org>; Wed, 18 Aug 2010 08:15:21 -0700 (PDT)
Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 18 Aug 2010 08:15:55 -0700
From: Jean-Francois Bertrand <jeffy@broadsoft.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Wed, 18 Aug 2010 08:15:50 -0700
Thread-Topic: Clarifications concerning the repeatUntilComplete attribute
Thread-Index: Acs+6D4eHr7e6ZkbRSSnnJXIPLF4wg==
Message-ID: <D64134C7765B58448BEF1C5E0B4BBB1514AB685AEF@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D64134C7765B58448BEF1C5E0B4BBB1514AB685AEFEXMBXCLUS01ci_"
MIME-Version: 1.0
Subject: [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: Wed, 18 Aug 2010 15:15:25 -0000

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>).  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 repeatUntilComplete set 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.