[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [198.152.13.100]) 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) ([198.152.7.5]) 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) ([135.9.6.103]) 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>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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 Server. 1 - Call Progress Tones. I see there was a discussion around this and possibly using H.248 tone definitions for country specific tones. http://www.ietf.org/mail-archive/web/mediactrl/current/msg01448.html 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 considered? 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> operation. 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 by 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 Division * pessot@avaya.com <mailto:pessot@avaya.com> * +1 303-538-1203
- [MEDIACTRL] MEDIACTRL questions from a new AS dev… Pessot, Albert D (Al)