[MEDIACTRL] MEDIACTRL questions from a new AS developer

"Pessot, Albert D (Al)" <pessot@avaya.com> Tue, 12 October 2010 21:48 UTC

Return-Path: <pessot@avaya.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 54B3B3A6A72 for <mediactrl@core3.amsl.com>; Tue, 12 Oct 2010 14:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id O1nshm4s-uQp for <mediactrl@core3.amsl.com>; Tue, 12 Oct 2010 14:48:35 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com []) by core3.amsl.com (Postfix) with ESMTP id 29C8C3A6A92 for <mediactrl@ietf.org>; Tue, 12 Oct 2010 14:48:35 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.57,322,1283745600"; d="scan'208,217"; a="242394578"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Oct 2010 17:49:50 -0400
X-IronPort-AV: E=Sophos; i="4.57,322,1283745600"; d="scan'208,217"; a="525877847"
Received: from unknown (HELO 306181ANEX3.global.avaya.com) ([]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Oct 2010 17:49:50 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6A57.64DC3E31"
Date: Tue, 12 Oct 2010 15:49:48 -0600
Message-ID: <15812D0154E5E840887A42B1BF154A6B0305347A@306181ANEX3.global.avaya.com>
Thread-Topic: MEDIACTRL questions from a new AS developer
thread-index: ActqV2RCk0XTGWkLT9CHtbRUL1TQRg==
From: "Pessot, Albert D (Al)" <pessot@avaya.com>
To: <mediactrl@ietf.org>
Subject: [MEDIACTRL] MEDIACTRL questions from a new AS developer
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: Tue, 12 Oct 2010 21:48:41 -0000

Greetings, I've only recently been thrown into the MEDIACTRL world and 

after reading the most recent RFC drafts I do have some questions.

I did search through the archives but didn't necessarily find answers to
my satisfaction.

I apologize if these things have been discussed and already resolved.


I'm asking these questions from the perspective of an Application


1 - Call Progress Tones. I see there was a discussion around this and
possibly using

      H.248 tone definitions for country specific tones.


      Based on the absence of any mention of call progress tones the
result seems to be

      to just have these configure locally on the media server.

      My specific question is whether the <tonegen> element as described
in MSML 

      http://tools.ietf.org/html/draft-saleem-msml-08#page-180 was

      This would give the AS complete flexibility in defining the tones
needed with no

      need to force media servers to support specific tones.


2 - In the ivr package, was there any thought given to a <dialogmodify>

     I can imagine needing to change some parameters (inter-digit
timeout?) and it looks like

     I can only do this by terminating the current <collect> dialog and
starting a new one.

     This seems dangerous if the media server is reporting DTMF events
at the start of a DTMF tone.

     There exists the possibility of the same DTMF tone being reported

     the old and then the new dialog.


3 - In the ivr package, the <clamp> operation is defined to block DTMF
from being sent on

     an outgoing media stream, but there is no ability for the AS to
subscribe to such an event.

     This would be necessary in the case where one media stream is setup
with RFC2833 or in-band DTMF

     and the other SIPUA wants to see digits out-of-band via INFO. Also
in the case of a SIPUA

     and an H.245 device where DTMF from the SIPUA needs to be converted
to H.245 UUIs.


4 - There is no mention in the ivr package to any form of tone detection
other than DTMF.

      What about detection of call progress tones, or detection of human
speech on answer

      for an outbound call center application?


Thanks very much.

Al Pessot  | Consulting Engineer |  AVAYA Converged Communications
*  pessot@avaya.com <mailto:pessot@avaya.com>   * +1 303-538-1203