WO2003039122A1 - Verfahren und system zum dynamischen generieren von ansageinhalten - Google Patents

Verfahren und system zum dynamischen generieren von ansageinhalten Download PDF

Info

Publication number
WO2003039122A1
WO2003039122A1 PCT/DE2002/004029 DE0204029W WO03039122A1 WO 2003039122 A1 WO2003039122 A1 WO 2003039122A1 DE 0204029 W DE0204029 W DE 0204029W WO 03039122 A1 WO03039122 A1 WO 03039122A1
Authority
WO
WIPO (PCT)
Prior art keywords
announcement
file
files
template
parameter values
Prior art date
Application number
PCT/DE2002/004029
Other languages
English (en)
French (fr)
Inventor
Detlev Freund
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE10200855A external-priority patent/DE10200855A1/de
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2003039122A1 publication Critical patent/WO2003039122A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/002—Details
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
    • H04M3/493—Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034—A/D conversion, code compression/expansion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1305—Software aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13175—Graphical user interface [GUI], WWW interface, visual indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13352—Self-routing networks, real-time routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13377—Recorded announcement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1338—Inter-exchange connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Definitions

  • the invention relates to a method for carrying out an acoustically reproducible announcement in a telecommunications network.
  • announcements and dialogues are necessary in certain situations, such as when a number is invalid ("No connection under this number. * Or 'The subscriber's number has changed and is now" .J ") or when querying subscriber data for the use of IN services in an intelligent network (IN).
  • IVR system ⁇ Interactive Voice System '
  • Sources of the announcements considered here are, in particular, switching-related events, such as: the dialing of an unconnected number or a number with a waiting system; Services implemented by a switching center that use a dialog, e.g. dialog-assisted control of subscriber self-inputs; or IN services with user dialogues, which are controlled via the interface between the switching center assigned to the subscriber and the SCP ("Signal Control Point", setting up the IN for controlling IN services).
  • switching-related events such as: the dialing of an unconnected number or a number with a waiting system; Services implemented by a switching center that use a dialog, e.g. dialog-assisted control of subscriber self-inputs; or IN services with user dialogues, which are controlled via the interface between the switching center assigned to the subscriber and the SCP ("Signal Control Point", setting up the IN for controlling IN services).
  • announcement should also include interactive announcements, i.e. dialogues.
  • control logic for executing the announcements is in the exchange or in the stations connected to the exchange (e.g. the SCP), but not in the IVR system, which requires a control interface via which the announcements can be controlled, including variable ones Announcement parameters and the feedback of collected user input between the switching center and IVR system can take place.
  • Information parameters, control parameters and input parameters are distinguished as parameters used here.
  • Information parameters indicate variable content, e.g. a phone number;
  • Control parameters affect the course of the announcement, e.g. the (maximum) number of passes of an announcement, the duration of a pause between repetitions;
  • Input parameters refer to inputs that are collected by the participant, e.g. the minimum number of dialing digits to be entered by the participant.
  • a known solution for the parameterized execution of announcements is based on the coded processing of parameters.
  • the logic for handling the control and input parameters is hard-coded in the control of the IVR system.
  • the user is only allowed one way of designing the announcements; Announcements can be changed using proprietary facilities and procedures.
  • This solution allows full access to parameters in the announcements, which can also contain variable content controlled by parameters.
  • it always represents a proprietary solution that is usually not very flexible and in which the transmission of announcements between different systems is severely restricted. This deficiency is largely avoided by an approach based on the standardized description language VoiceXML.
  • the VoiceXML language (Noice eXtensible Markup Language ') was designed as a markup language for the generation of audio dialogues; Their main task is to enable the advantages of web-based developments and web content transmissions for interactive voice response systems, too, with dialogues involving synthetic speech, digital audio information, recognition of spoken and DTMF inputs, recording spoken input, telephony and dialogues, which can be initiated both by the user and by the computer-controlled side, are possible.
  • the VoiceXML language please refer to the VoiceXML 2.0 standard of the WWW Consortium W3C (http://www.voicexeml.org and http://www.w3.org/TR/).
  • the IVR system has set up a VoiceXML browser for interpreting VoiceXML pages; An announcement or a dialog is described in these VoiceXML pages - analogous to the way in which an HTML page shows a graphic output (which is output by an HTML browser).
  • the associated input parameters are resolved in a so-called grammar file that is assigned to the relevant VoiceXML page.
  • known solutions based on VoiceXML are based on the assumption that the entire announcement can proceed without external control interventions; in particular, the processing of control parameters and thus the consideration of parameter-controlled variable parts of an announcement is not provided.
  • the operator should be able to easily and flexibly make announcements (including dialogs) using announcement-specific parameters. meters and in particular to use and change control parameters.
  • the object is achieved by a method of the type mentioned at the beginning with the following steps:
  • This solution fulfills the task in a simple manner.
  • an additional step in the processing of the request for an announcement namely the creation of an announcement file from a template - instead of using pre-prepared, constant announcements - the flexible design of parameterized announcements succeeds.
  • a server device for announcement files with an interface to an announcement device which contains an interpreter module for the interpretation of announcement files as acoustically reproducible announcements, and is configured with a preprocessor device according to the invention to receive announcement-specific parameter values and starting from open ones is particularly suitable for the implementation of the invention Create parameters relating to the content and / or the execution of an announcement containing template files in dependence on the parameter values of announcement files in which the open parameters of the template file (s) are resolved.
  • an announcement system for providing acoustically reproducible announcements in a telecommunication network, with an interface device for connection to the telecommunication network and to a control point assigned to the telecommunication network with a storage device and with an interpreter module for the interpretation of announcement files as acoustically reproducible announcements, as well as with a preprocessor device of the type according to the invention.
  • template and announcement files written according to a markup language are used, e.g. according to the VoiceXML language.
  • This is particularly in connection with data networks such as a LAN network or the Internet, where the use of markup documents (e.g. HTML or WML pages) is common from text and graphics applications.
  • the template files used for this purpose can be selected by the preprocessor device from a number of template files depending on the parameter values before the announcement file is created.
  • the template files can be kept, for example, in a memory provided for this purpose.
  • the announcement file when the announcement file is created, provided that the template file contains commands relating to an input, additional input files for the interpretation of inputs during an announcement are created.
  • the input files can be temporarily stored in a file memory and then called up from there when the relevant inputs are carried out.
  • FIG. 1 shows the networks and network components involved in establishing a Voice-over-IP connection between two network subscribers
  • FIG. 4 shows a signal sequence for an announcement dynamically created according to the invention.
  • VoIP Voice-over-IP technology
  • a VoIP connection is established for a calling subscriber TN1 of a telephone network NE1 via the Internet IPN (or another packet-oriented data network) to a called subscriber TN2 of a telephone network NE2, which is usually - but not necessarily - from the network NE1 is different.
  • the connection of the subscribers TN1, TN2 to the networks is implemented in a known manner via switching centers VS1 and VS2; for the transitions from the telephone networks NE1, NE2 to the Internet IPN, VoIP gateways IG1, IG2 are set up for the purposes of VoIP.
  • the network NE1 is an ISDN network, to which a service control SCI of a known type, which in particular comprises an SCP, is assigned to carry out intelligent network services.
  • a gateway controller GCl is provided in a known manner for the control and monitoring of the VoIP connections. This controls in particular the gateways IG1, IG2 and coordinated rences them together using a control protocol (GCP, "Gateway Control Prot.ocol ') of a known type, for example H.GCP or MGCP; in the exemplary embodiment considered below, the MGCP protocol is preferably used (cf. RFC-2705 and' RFC 2897 ; see, for example, "http://www.rfc-editor.org/”), the controller being referred to as MGC ( ⁇ Media Gateway Controller ').
  • the gateway controller GC1 also communicates with the switching centers VS1.
  • an announcement system VAS is provided, which with the controller GC1 ' type via a control protocol such as the gateways IG1, IG2 communicates the announcement system VAS is realized in known implementations using an IVR system of a known type;.... to the invention is as explained below 'to parametrisi. Erten create announcements expanded 'tert.
  • the connections between network stations is exchanged via the control information only, shown dotted '.
  • a template vtm is used, which is based on VoiceXML, for example, but in which parameter fields are kept open, which are to be resolved according to the values of announcement parameters.
  • an announcement file vpg for example a VoiceXML
  • a preprocessor PPZ for example a VoiceXML
  • the parameter values prv adopted by the IVR system can be processed dynamically.
  • Associated announcement templates are prepared for each type of announcement. These templates can be obtained from the provider of the announcement system and / or the operator of the network can be changed at any time in any way and thus be adapted to the respective requirements.
  • the preprocessor processes a template in order to create an announcement from it - more precisely one or more announcement files on the basis of which an announcement is carried out - the parameter fields contained in the template are resolved.
  • the values of the information parameters are inserted by the preprocessor into the corresponding parameter fields of the relevant announcement file and thus integrated into the announcement.
  • Input parameters are resolved in a corresponding manner, and according to the structure of the language on which the input is based, a separate input file - namely a so-called grammar file in the case of VoiceXML - can be created on the basis of an input template;
  • a link (reference) to the input file is inserted at the location provided for the input.
  • Control parameters are implemented by the preprocessor, depending on the type of parameter, using references between announcement files; e.g. A control parameter relating to the number of repetitions is implemented by using a corresponding number of references to a second announcement file (which contains the parts of the announcement to be repeated) in a first announcement file.
  • the announcement files created by the preprocessor according to the invention can be interpreted directly by the IVR system.
  • the announcement files are preferably VoiceXML pages corresponding to the known standards and can be interpreted by any VoiceXML browser.
  • the content of the announcement can thus be modified externally based on the standards that are subject to the announcement file, such as VoiceXML. This eliminates the need for proprietary interfaces to generate announcements based on the invention.
  • a preprocessor which generates the announcement files of the announcement to be played dynamically and in dependence on the transferred parameter values provides the announcement system (more precisely the interpreter / browser), a flexible and at the same time simple realization of announcements taking into account announcement parameters.
  • the system VAS comprises an announcement server VSV (also called ⁇ Voice Server '), to which requests for announcements are sent in a known manner by the controller GC1 or by the service control SCI and which these announcements are based on announcement files in the form of VoiceXML pages plays, and a content server CSV ( ⁇ Content Server '), which is used to provide the announcement files or VoiceXML pages.
  • VSV also called ⁇ Voice Server '
  • a content server CSV ⁇ Content Server '
  • the announcement server VSV and the content server CSV can be separate devices that are connected to one another via an interface, or can be implemented together in a system of the announcement system VAS.
  • the announcement server VSV contains, in a known manner, an interface device VIF, which interfaces to the gateway controller GC1 and to the Internet IPN (generally to the associated telecommunications network via which the announcements are to be output), and a browser VBR for playing the announcement files.
  • VIF interface device
  • IPN generally to the associated telecommunications network via which the announcements are to be output
  • a browser VBR for playing the announcement files.
  • the content server CSV has a memory CSS which, for example holds the template files according to the invention as well as the temporarily stored announcement and / or grammar files in their own partial memories TMS, GRS, WFS; the memory CSS can advantageously also contain sound files wfi which are required for the acoustic interpretation of the announcement files, for example sound files in the form of WAV files in a sound file memory WFS.
  • the content server CSV analyzes and evaluates the MGCP message in an MGCP parser PPS belonging to the preprocessor PPZ.
  • grammar files grm serving as the input files are also required for the definition of the inputs. Based on the template vtm, these are generated by a grammar module GRB ( x Grammar Builder ') and stored in a GRS memory.
  • GRB x Grammar Builder '
  • the browser VBR can then retrieve the grammars grm using the references in the page vpg via HTTP request crq.
  • Example 1 shown below shows an exemplary grammar template, as well as Example 2 a grammar file created on the basis of this template, in which it is specified that only 2 to 3 digits are allowed for an entry.
  • the system distinguishes a simple announcement from an interactive announcement (a dialog) based on appropriate MGCP keywords.
  • These commands pa and p also lead to various HTTP requests.
  • the procedure for performing an announcement is in the signal flow diagram of FIG. 4, in which the vertical axis corresponds to the time axis and vertical lines represent stations between which signals and data are exchanged.
  • Example 1 Grammar template ; Gives the result of DTMF Voice recognition as a string; FIRST PART: TEMPLATE PREDEFINED FOR EACH LANGUAGE DIGIT
  • Example 2 Grammar file For the sake of clarity, only the stations SCI or GCl, VSV, CSV and TN2 relevant for the signal curve are shown (cf. FIG. 1). The numbers used in Fig. 4 correspond to the numbering of the sequence used below.
  • the announcement server VSV receives an MGCP message, in which the playing of an announcement (in the example shown here a dialog with a subscriber would be entered) is requested.
  • An exemplary MGCP message of this type is shown in Example 3; the parameters are contained in the last line of the example.
  • the server VSV sends an HTTP request - example 4 -, which contains the information of the MGCP message 1, to the content server CSV.
  • the preprocessor PPZ is started on the basis of request 2. This processes the request and evaluates the announcement parameters contained therein, on the basis of this creates a VoiceXML page vpg from the relevant template files vtm, as well as corresponding grammar files grm for handling subscriber entries; the grammar files are referenced by links in the VoiceXML page vpg. At this point, links to the sound files wfi required to play the announcement are also included in the vpg page.
  • Example 5 shows such a VoiceXML page; the associated grammar file corresponds to that shown in Example 2.
  • the VoiceXML page vpg is returned from the content server CSV as an HTTP response to the announcement server VSV.
  • the VSV server starts interpreting the vpg page; the required grammar and sound files are determined.
  • the announcement is played by the announcement server in accordance with the VoiceXML file vpg; the participant's input 8 'is evaluated on the basis of the grammar file grm.
  • connection between the subscribers TN1, TN2 can also be of a different type than VoIP, namely e.g. implemented entirely via analog and / or digital telecommunications networks, and the announcement station VAS e.g. be assigned to the network NE1 or NE2.
  • the subscriber to whom the announcement is played can also be an IP subscriber in accordance with ITU-T standard H.323.
  • the realization of the announcement and input files can also be based on a different format than that of a markup language such as VoiceXML.
  • WAV-files names are generated according to INFRAGM numbers and appropri - ate language .
  • Variant assign ent var

Abstract

Um eine Ansage in einem Telekommunikationsnetz durchzuführen, wird, aufgrund der von einer Steuerstelle des Netzes gesendeten Anforderung für die Ansage mit Ansagen-spezifischen Parameterwerten (aid,prv), aus einer Vorlagedatei (vtm) eine Ansagedatei erstellt. Hierbei werden in der Vorlagedatei (vtm) enthaltene offene Parameter betreffend den Inhalt und/oder die Ausführung der Ansage in der Ansagendatei (vpg) in Abhängigkeit von den Parameterwerten (prv) aufgelöst. Die so erhaltene Ansagedatei, z.B. in Form einer VoiceXML-Seite, kann dann interpretiert und über das Telekommunikationsnetz ausgegeben werden.

Description

VERFAHREN UND SYSTEM ZUM DYNAMISCHEN GENERIEREN VON ANSAGE INHALT hi
Beschreibung
Verfahren und System zum dynamischen Generieren von Ansageinhalten
Die Erfindung betrifft ein Verfahren zur Durchführung einer akustisch wiedergebbaren Ansage in einem Telekommunikationsnetz .
In Telekommunikationsnetzen gehört es unter Anderem zu den Aufgaben der Vermittlungsstellen, den Teilnehmern beim Herstellen oder Bearbeiten von Telekommunikationsverbindungen Ansagen und Dialoge anzubieten. Diese Ansagen und Dialoge werden in gewissen Situationen notwendig, wie z.B. bei der Ungültigkeit einer Nummer („Kein Anschluss unter dieser Nummer . * bzw. 'Die Rufnummer des Teilnehmers hat sich geändert und ist nunmehr ,.J ) oder bei der Abfrage von Teilnehmerdaten für die Benutzung von IN-Diensten in einem Intelligenten Netz (IN) . Diese Ansagen und Dialoge werden in der Regel von einer von den Vermittlungsstellen gesonderten Anlage durchgeführt, die auch unter dem Begriff IVR-System ( λInteractive Voice System') bekannt ist.
Entstehungsquellen der hier betrachteten Ansagen sind insbesondere vermittlungstechnische Ereignisse, wie z.B.: die Wahl einer unbeschalteten Rufnummer oder einer Rufnummer mit einem Wartesystem; seitens einer Vermittlungsstelle realisierte Dienste, welche einen Dialog nutzen, z.B. eine Dialogunterstützte Steuerung von Teilnehmer-Selbsteingaben; oder IN-Dienste mit Nutzerdialogen, deren Steuerung über die Schnittstelle zwischen der dem Teilnehmer zugeordneten Vermittlungsstelle und dem SCP ("Signal Control Point', Einrichtung des IN zur Steuerung von IN-Diensten) erfolgt.
Im Folgenden soll der Begriff der Ansage, soweit nicht ausdrücklich etwas anderes angemerkt ist, auch interaktive Ansagen, also Dialoge, einschließen. In den bisher verwendeten Fällen liegt die Steuerlogik zur Durchführung der Ansagen in der Vermittlungsstelle oder in den an die Vermittlungsstelle angeschlossenen Stationen (z.B. dem SCP) , nicht jedoch im IVR-System, was eine Steuerschnittstelle erforderlich macht, über die die Steuerung der Ansagen einschließlich variabler Ansageparameter sowie die Rückmeldung von eingesammelten Nutzereingaben zwischen Vermittlungsstelle und IVR-System erfolgen kann.
Um die erwähnte Steuerschnittstelle zu vermeiden, werden Lösungen gesucht, bei denen die Verarbeitung der Ansageparameter und Ausgabe von Ansagen und Dialogen gemäß den aktuellen Werten der Parameter seitens des IVR-Systems durchführbar ist. Als hierbei verwendete Parameter werden Informationsparameter, Steuerparameter und Eingabeparameter unterschieden. Informationsparameter geben variable Inhalte an, z.B. eine Telefonnummer; Steuerparameter betreffen den Ablauf des Ansage, wie z.B. die (maximale) Anzahl der Durchläufe einer Ansage, die Dauer einer Pause zwischen Wiederholungen; Eingabeparameter beziehen sich auf Eingaben, die vom Teilnehmer eingesammelt werden, wie z.B. die Mindestanzahl von Wahlziffern, die vom Teilnehmer einzugeben sind.
Eine bekannte Lösung zur parametrisierten Ausführung von Ansagen beruht auf der kodierten Verarbeitung von Parametern. Hierbei ist die Logik zur Behandlung der Steuer- und Eingabeparameter in der Steuerung des IVR-Systems fest kodiert. Dem Anwender wird nur eine Möglichkeit der Gestaltung der Ansagen zugelassen; eine Änderung von Ansagen ist über proprietäre Einrichtungen und Verfahren möglich. Diese Lösung gestattet vollen Zugriff auf Parameter in den Ansagen, die auch durch Parameter gesteuerte variable Inhalte enthalten können. Jedoch stellt sie stets eine proprietäre Lösung dar, die in der Regel wenig flexibel ist und bei der die Übertragung der Ansagen zwischen verschiedenen Anlagen stark eingeschränkt ist. Dieser Mangel wird in durch einen auf der standardisierten Beschreibungssprache VoiceXML beruhenden Ansatz weitgehend vermieden. Die Sprache VoiceXML ( Noice eXtensible Markup Language' ) wurde als Markup-Sprache für die Erzeugung von Audio-Dialogen entworfen; ihre Hauptaufgabe ist es, die Vorteile Web-basierter Entwicklungen und Web-Inhalts-Übertra- gungen auch für interaktive Sprachantwort-Systeme zu ermöglichen, wobei Dialoge unter Einbeziehung synthetischer Sprache, digitaler Audio-Information, der Erkennung von gesprochenen und DTMF-Eingaben, Aufnahme gesprochener Eingaben, Telefonie und von Dialogen, die sowohl vom Benutzer als auch von computergesteuerter Seite initiierbar sind, möglich sind. Für nähere Details zur VoiceXML-Sprache sei auf den Standard VoiceXML 2.0 des WWW-Consortiums W3C (http://www.voicexeml.org sowie http://www.w3.org/TR/) verwiesen.
Nach diesem Ansatz ist seitens des IVR-Systems ein VoiceXML- Browser für die Interpretation von VoiceXML-Seiten eingerichtet; in diesen VoiceXML-Seiten ist eine Ansage bzw. ein Dialog beschrieben - analog dazu, wie in einer HTML-Seite eine graphische Ausgabe (die durch einen HTML-Browser ausgegeben wird) dargestellt ist. Für Eingaben, die im Rahmen eines Dialogs durch den Benutzer zu tätigen sind, werden die zugehörenden Eingabeparameter in einer sogenannten Grammar-Datei, die der betreffenden VoiceXML-Seite zugeordnet ist, aufgelöst. Jedoch beruhen bekannte, auf VoiceXML basierende Lösungen auf der Annahme, dass die gesamte Ansage ohne externe Steuerungseingriffe ablaufen kann; insbesondere ist die Abarbeitung von Steuerparametern und somit eine Berücksichtigung Parameter-gesteuerter variabler Anteile einer Ansage nicht vorgesehen.
Es ist Aufgabe der Erfindung, die Ausführung von Ansagen und Dialogen, insbesondere auf einer Markup-Sprache wie VoiceXML beruhenden, zu verbessern. Hierbei soll es dem Betreiber auf einfache und flexible Weise möglich sein, Ansagen (einschließlich Dialoge) unter Einsatz Ansagen-spezifischer Para- meter und insbesondere Steuerparameter einzusetzen und zu ändern.
Die gestellte Aufgabe wird erfindungsgemäß von einem Verfahren der eingangs genannten Art mit den folgenden Schritten gelöst:
- Empfangen einer von einer Steuerstelledes Telekommunikationsnetzes gesendeten Anforderungfür eine Ansage und Ermitteln Ansagen-spezifischer Parameterwerte
- Erstellenzumindest einer Ansagendateiaus zumindest einer Vorlagedatei, die offene Parameter betreffend den Inhalt und/oder die Ausführung einer Ansage enthält, wobei in der Ansagendateidie offenen Parameter der Vorlagedatei (en) in Abhängigkeit von den Parameterwertenaufgelöst werden, und
- Interpretationder zumindest einen Ansagedateiais Ansage, wobei die Ansage über das Telekommunikationsnetz ausgegeben wird.
Diese Lösung erfüllt die gestellte Aufgabe auf einfache Weise. Durch die Einführung eines zusätzlichen Schrittes in die Verarbeitung der Anforderung einer Ansage, nämlich die Erstellung einer Ansagendatei aus einer Vorlage - anstelle der Verwendung vorgefertigter, gleichbleibender Ansagen - gelingt die flexible Gestaltung von parametrisierten Ansagen.
Für die Realisierung der Erfindung eignet sich besonders eine Servereinrichtungfür Ansagedateien mit einer Schnittstelle zu einer Ansageeinrichtung, welche ein Interpretermodulfür die Interpretation von Ansagedateien als akustisch wiedergebbare Ansagen enthält, und mit einer Präprozessoreinrichtungweiche nach der Erfindung dazu eingerichtet ist, Ansagen-spezifische Parameterwerteentgegenzunehmen und ausgehend von offene Parameter betreffend den Inhalt und/oder die Ausführung einer Ansage enthaltende Vorlagedateienin Abhängigkeit von den ParameterwertenAnsagedateienzu erstellen, in denen die offenen Parameter der Vorlagedatei (en) aufgelöst sind. Ebenso ist für die Verwirklichung der Erfindung ein Ansage- systemzur Bereitstellung von akustisch wiedergebbaren Ansagen in einem Telekommunikationsnetz geeignet, mit einer Schnittstelleneinrichtungzur Anbindung an das Telekommunikationsnetz und an eine dem Telekommunikationsnetz zugeordnete Steuerstellemit einer Speichereinrichtungund mit einem Interpretermodulfür die Interpretation von Ansagedateien als akustisch wiedergebbare Ansagen, sowie mit einer Präprozessoreinrichtung der genannten erfindungsgemäßen Art.
In einer bevorzugten Ausführungsform der Erfindung werden gemäß einer Markup-Sprache abgefasste Vorlage- und Ansagedateien verwendet, z.B. gemäß der VoiceXML-Sprache. Dies ist insbesondere im Zusammenhang mit Datennetzen wie z.B. einem LAN-Netzwerk oder dem Internet, von Vorteil, wo die Verwendung von Markup-Dokumenten (z.B. HTML oder WML-Seiten) von Text- und Graphik-Anwendungen her geläufig ist.
In einer bevorzugten Variante der Erfindung können vor dem Erstellen der Ansagedatei die hierfür verwendeten Vorlagedateien von der Präprozessoreinrichtung aus einer Anzahl von Vorlagedateien in Abhängigkeit von den Parameterwerten ausgewählt werden. Die Vorlagedateien können beispielsweise in einem hierfür vorgesehenen Speicher gehalten werden.
Des weiteren ist es für den Fall interaktiver Ansagen (Dialoge) vorteilhaft, wenn beim Erstellen der Ansagedatei, sofern die Vorlagedateisich auf eine Eingabe beziehende Befehle enthält, zusätzlich Eingabedateienfür die Interpretation von Eingabenwährend einer Ansage erstellt werden. Hierbei können die Eingabedateienin einem Dateispeicherzwischengespeichert werden und danach von dort bei der Ausführung der betreffenden Eingaben abgerufen werden.
Die Erfindung samt weiterer Vorzüge wird im folgenden unter Zuhilfenahme beigefügter Zeichnungen und Beispiele näher erläutert. Diese stellen insbesondere ein bevorzugtes, nicht einschränkendes Ausführungsbeispiel der Erfindung dar, das sich auf die Durchführung von parametrisierten Ansagen für Voice-over-IP-Verbindungen bezieht. Die Zeichnungen zeigen in schematischer Form
Fig. 1 die am Aufbau einer Voice-over-IP-Verbindung zwischen zwei Netzteilnehmern beteiligten Netze und Netzkomponenten;
Fig. 2 die dynamische Erstellung von Ansagendateien nach dem Erfindungsprinzip;
Fig. 3 eine erfindungsgemäßes Ansagesystem;
Fig. 4 einen Signalablauf für eine erfindungsgemäß dynamisch erstellte Ansage.
Das im Folgenden dargestellte Ausführungsbeispiel bezieht sich auf Telefonverbindungen unter Nutzung der bekannten Voice-over-IP-Technologie (VoIP) und im Zusammenhang damit durchzuführende Ansagen. Bezugnehmend auf Fig. 1 wird eine VoIP-Verbindung für einen rufenden Teilnehmer TN1 eines Telefonnetzes NE1 über das Internet IPN (oder ein anderes paketorientiertes Datennetz) zu einem gerufenen Teilnehmer TN2 eines Telefonnetzes NE2 hergestellt, das in der Regel - jedoch nicht notwendigerweise - vom Netz NE1 verschieden ist. Die Anbindung der Teilnehmer TN1,TN2 an die Netze ist nach bekannter Art über Vermittlungsstellen VS1 bzw. VS2 realisiert; für die Übergänge von den Telefonnetzen NE1,NE2 zum Internet IPN sind für die Zwecke des VoIP jeweils VoIP- Gateways IG1,IG2 eingerichtet. Das Netz NE1 ist in dem hier betrachteten Ausführungsbeispiel ein ISDN-Netz, dem zur Durchführung intelligenter Netzdienste eine Dienstesteuerung SCI bekannter Art zugeordnet ist, die insbesondere einen SCP umfasst .
Für die Steuerung und Überwachung der VoIP-Verbindungen ist nach bekannter Art ein Gateway-Controller GCl vorgesehen. Dieser steuert insbesondere die Gateways IG1,IG2 und koordi- niert sie miteinander unter Verwendung eines Steuerungsprotokolls (GCP, "Gateway Control Prot.ocol') bekannter Art, z.B. H.GCP oder MGCP; in dem im Folgenden betrachteten Ausführungsbeispiel wird vorzugsweise das MGCP-Protokoll (vgl. RFC- 2705 und' RFC 2897; sh. z.B. "http://www.rfc-editor.org/") verwendet, wobei der Controller als MGC ( λMedia Gateway Controller' ) bezeichnet wird. Darüber hinaus kommuniziert der Gateway-Controller GC1 auch mit den Vermittlungsstellen VS1.,VS2 - z.B. über das bekannte SS7-Protokoll - und mit der : Dienstesteuerung SCI. Für die Durchführung von Ansagen, die. im Zusammenhang mit VoIP-Verbindungen erforderlich sind, ist ein Ansagesystem VAS vorgesehen, das mit dem Controller GC1 ' . nach bekannter Art über ein Steuerungsprotokoll wie die Gateways..IG1, IG2 kommuniziert. Das Ansagesystem VAS ist in bekannten -Implementierungen mittels eines IVR-Systems bekannter. Art realisiert; nach der Erfindung ist es wie weiter unten . erläutert ' zur parametrisierten Erstellung von Ansagen erwei- ' tert. In Fig. 1 sind die Verbindungen zwischen Netzstationen, über die lediglich Steuerinformation ausgetauscht wird, gepunktet dargestellt'.
Das Grundprinzip der Erfindung für die dynamische Erstellung von Ansagen ist in Fig. 2 schematisch dargestellt. Zur Definition einer Ansage wird eine Vorlage vtm verwendet, die beispielsweise auf VoiceXML beruht, in der jedoch Parameterfelder offen gehalten sind, die gemäß den Werten von Ansagenparametern aufzulösen sind. Aus der Vorlage wird, wenn die betreffende Ansage - z.B. durch eine Ansage-Identifikation aid bezeichnet - aufgerufen wird, mithilfe eines Präprozessors PPZ unter Verwendung der von der Vermittlungsstelle bzw.. dem SCP übergebenen Werte prv der Ansageparameter eine Ansagedatei vpg erstellt, z.B. eine VoiceXML-Seite, die von einem Interpreter (z.B. VoiceXML-Browser) VBR interpretierbar ist. Auf diese Weise können die vom IVR-System übernommenen Parameterwerte prv dynamisch verarbeitet werden. Für jeden Typ einer Ansage sind zugehörende Ansage-Vorlagen vorbereitet. Diese Vorlagen können von dem Anbieter des Ansagesystems und/oder dem Betreiber des Netzes jederzeit in beliebiger Weise geändert werden und so den sich jeweils ergebenden Anforderungen angepasst werden.
Bei der Verarbeitung einer Vorlage durch den Präprozessor, um daraus eine Ansage - genauer eine oder mehrere Ansagedateien, anhand deren eine Ansage ausgeführt wird, - zu erstellen, werden die in der Vorlage enthaltenen Parameterfeider aufgelöst. Insbesondere werden die Werte der Informationsparameter durch den Präprozessor in die entsprechenden Parameterfelder der betreffenden Ansagedatei eingesetzt und so in die Ansage integriert. Eingabeparameter werden in entsprechender Weise aufgelöst, wobei gemäß der Struktur der zugrunde liegenden Sprache für die Eingabe eine eigene Eingabedatei - nämlich im Fall des VoiceXML eine sogenannte Grammardatei - aufgrund einer Eingabevorlage erstellt werden kann; in der Ansagedatei wird an der für die Eingabe vorgesehenen Stelle eine Verknüpfung (Referenz) auf die Eingabedatei eingesetzt. Steuerparameter werden vom Präprozessor je nach Art des Parameters mithilfe von Referenzen zwischen Ansagedateien verwirklicht; z.B. wird ein die Anzahl der Wiederholungen betreffender Steuerparameter dadurch realisiert, dass in einer ersten Ansagedatei eine entsprechende Anzahl von Referenzen auf eine zweite Ansagedatei (die die zu wiederholenden Teile der Ansage enthält) eingesetzt werden.
Die vom Präprozessor erfindungsgemäß erstellten Ansagedateien sind von dem IVR-System unmittelbar interpretierbar. Vorzugsweise sind die Ansagedateien den bekannten Standards entsprechende VoiceXML-Seiten und können von jedem VoiceXML-Browser interpretiert werden. Der Inhalt der Ansage kann somit extern aufgrund der Standards, die der Ansagedatei unterliegen, wie z.B. VoiceXML, modifiziert werden. Somit erübrigen sich aufgrund der Erfindung proprietäre Schnittstellen zur Ansageerzeugung. Durch die Einführung eines Präprozessors, welcher die Ansagedateien der abzuspielenden Ansage dynamisch und in Abhängigkeit von den übergebenen Parameterwerten erzeugt und dem Ansagesystem (genauer dem Interpreter/Browser) zur Verfügung stellt, gelingt eine flexible und zugleich einfache Realisierung von Ansagen unter Berücksichtigung von Ansagepara- metern.
Fig. 3 zeigt ein Ansagesystem VAS zur erfindungsgemäßen dynamischen Erstellung und Durchführung von Ansagen gemäß dem Ausführungsbeispiel . Das System VAS umfasst einen Ansageserver VSV (auch ΛVoice Server' genannt) , an den nach bekannter Art vom Controller GC1 bzw. von der Dienstesteuerung SCI Anforderungen für Ansagen gesendet werden und der diese Ansagen auf der Grundlage von Ansagedateien in Form von VoiceXML- Seiten abspielt, und einen Inhaltsserver CSV ( ΛContent Server' ) , der der Bereitstellung der Ansagedateien bzw. VoiceXML-Seiten dient.
Der Ansageserver VSV und der Inhaltsserver CSV können getrennte Einrichtungen sein, die über eine Schnittstelle miteinander verbunden sind, oder gemeinsam in einer Anlage des Ansagesystems VAS verwirklicht sein. Der Ansageserver VSV enthält nach bekannter Art ein Schnittstelleneinrichtung VIF, der die Schnittstellen zu dem Gateway-Controller GC1 sowie zum Internet IPN (im Allgemeinen zum zugeordneten Telekommunikationsnetz, über das die Ansagen auszugeben sind) , sowie einen Browser VBR zum Abspielen der Ansagedateien. Neben dem bereits im Zusammenhang mit Fig. 2 genannten Präprozessor PPZ, der z.B. als Software in Form eines sogenannten Servlets (d.i. kompilierter, seitens des Servers ausführbarer Java- Code) realisiert sein kann, weist der Inhaltsserver CSV einen Speicher CSS auf, der - z.B. in jeweils eigenen Teilspeichern TMS,GRS,WFS - die erfindungsgemäßen Vorlagendateien sowie zwischengespeicherte Ansagen- und/oder Grammardateien hält; der Speicher CSS kann vorteilhafter Weise auch Tondateien wfi enthalten, die bei der akustischen Interpretation der Ansagendateien benötigt werden, z.B. Tondateien in Form von WAV- Dateien in einem Tondateispeicher WFS. Der Ansageserver VSV erhält die Ansagen-spezifischen Parameter aid,prv nach bekannter Art von der Dienstesteuerung SCI über den Gateway-Controller GC1 über das MGCP-Protokoll in Form einer MGCP-Nachricht und leitet diese über eine HTTP- Anforderung (= sogenannten "Request") an den Inhaltsserver CSV weiter. Seitens des Inhaltsservers CSV wird die MGCP- Nachricht in einem zum Präprozessor PPZ gehörenden MGCP- Parser PPS analysiert und ausgewertet. In einem Antwortmodul RPB ( λResponse Builder' ) wird gemäß den Parameterwerten aid,prv eine VoiceXML-Vorlage vtm aus einem Vorlagenspeicher TMS abgerufen und anhand dieser Vorlage eine VoiceXML-Seite vpg erstellt; diese wird in einer HTTP-Antwort (= sogenannten "Response") an den Ansageserver VSV zur Interpretation durch den Browser VBR zurück gegeben.
Wenn die angeforderte Ansage ein Dialog ist, so werden zusätzlich zur als Ansagedatei dienenden VoiceXML-Seite vpg auch als Eingabedateien dienende Grammar-Dateien grm für die Definition der Eingaben benötigt. Diese werden aufgrund der Vorlage vtm durch ein Grammarrαodul GRB ( xGrammar Builder' ) erzeugt und in einem Grammarspeicher GRS gespeichert. Bei der Interpretation der VoiceXML-Seite vpg als Dialog kann dann der Browser VBR die Grammars grm mittels der Referenzen in der Seite vpg per HTTP-Request crq abrufen.
.Das unten gezeigte Beispiel 1 zeigt eine beispielhafte Gram- mar-Vorlage, sowie das Beispiel 2 eine aufgrund dieser Vorlage erzeugte Grammar-Datei, in der festgelegt wird, dass bei einer Eingabe lediglich 2 bis 3 Ziffern erlaubt sind.
Das System unterscheidet eine einfache Ansage von einer interaktiven Ansage (einem Dialog) anhand entsprechender MGCP- Schlüsselwörter. Beispielsweise wird in einer einfachen Ansage der Befehl pa (= ^PlayAnnouncement' ) verwendet, wogegen in einem Dialog der Befehl pc (= ΛPlayCollect' ) verwendet wird, der auch das Einsammeln von Ziffern veranlasst. Diese Befehle pa bzw. p führen auch zu verschiedenen HTTP-Requests . Der Ablauf einer Ansagedurchführung ist in dem Signalablaufsdiagramm der Fig. 4, worin die vertikale Achse der Zeitachse entspricht und vertikale Linien Stationen darstellen, zwischen denen Signale und Daten ausgetauscht werden.
Gives the result of DTMF/engl. Voice recognition as a string FIRST PART: TEMPLATE PREDEFINED FOR EACH LANGUAGE DIGIT [ [ zero dtmf-θ { return("θ") } one dtmf-1
{ return("l") }
mne dtmf-9
{ return("9") } star dtmf -star
{ return("*") } hash dtmf-pound pound ] { return("#") } ] ; DTMF-values defined from MGCP for the following keys
; speech-recognition predefined ; Start Input Key SIK [ start SIK ] ; End Input Key EIK
[ end stop
EIK ]{ return("EIK") } ; Restart Key RIK [ cancel
RIK ]{ return(" ") }
Beispiel 1: Grammar-Vorlage ; Gives the result of DTMF/engl. Voice recognition as a string ; FIRST PART: TEMPLATE PREDEFINED FOR EACH LANGUAGE DIGIT
; ... (-» Tab.l) ; Start Input Key SIK
[ start dtmf-star ] ; End Input Key EIK [ end stop dtmf-pound ]{ return("#") } ; Restart Key RIK
[ cancel dtmf-star ]{ return(" ") }
FOLLOWING HA5 TO BE BUILD DYNAMICALLY following definition fro 1 to 3 digit
1DIGIT [ DIGIT:dl EIK:dl ]{ return($dl) } 2DIGIT
( DIGIT:dl lDIGIT:d2 ) { return(strcat($dl $d2 )) } 3DIGIT
( DIGIT:dl 2DIGIT:d2 ) { return(strcat($dl $d2 )) } 2-3DIGIT ( SIK [ 2DIGIT:dl{ return($dl) } 3DIGIT:dl{ return($dl) } 1DIGIT{ return(" ") } ] )
; following gives the result: possible are min=2 or max=3 digits
.DTMF (
?RIK
2-3DIGIT:dl
7( +RSK:dl 2-3DIGIT:dl ) ) { <dtmfstring $dl>}
Beispiel 2: Grammar-File Der besseren Übersichtlichkeit halber sind lediglich die für den Signalverlauf relevanten Stationen SCI bzw. GCl, VSV, CSV und TN2 (vgl. Fig. 1) gezeigt. Die in Fig. 4 verwendeten Nummern entsprechen der Nummerierung des folgend verwendeten Ablaufs .
1) Der Ansageserver VSV erhält eine MGCP-Nachricht, in der das Abspielen einer Ansage (im hier gebrachten Beispiel ein Dialog mit einer Teilnehmer eingäbe) angefordert wird. Eine beispielhafte MGCP-Nachricht dieser Art ist in Beispiel 3 gezeigt; die Parameter sind in der letzten Zeile des Beispiels enthalten.
2) Der Server VSV sendet einen HTTP-Request - Beispiel 4 -, der die Informationen der MGCP-Nachricht 1 enthält, an den Inhaltsserver CSV.
3) Aufgrund des Requests 2 wird der Präprozessor PPZ gestartet. Dieser verarbeitet den Request und wertet die darin enthaltenen Ansageparameter aus, erstellt aufgrund dessen eine VoiceXML-Seite vpg aus den betreffenden Vorlagendateien vtm, sowie entsprechende Grammar-Dateien grm zur Behandlung von Teilnehmer-Eingaben; die Grammar-Dateien werden durch Verknüpfungen in der VoiceXML-Seite vpg referen- ziert. An dieser Stelle werden auch gegebenenfalls Verknüpfungen mit den zum Abspielen der Ansage benötigten Tondateien wfi in die Seite vpg einbezogen. Beispiel 5 (sh. S. 15 f ) zeigt eine solche VoiceXML-Seite; die zugehörende Grammar-Datei entspricht der in Beispiel 2 gezeigten. Die Vorlagedatei, aus der die VoiceXML-Seite erzeugt
MDCX 4721 LC1/LINE1/12@MGW01. SIEMENS. DE MGCP 1.0
C 1234
I E23D48
X 3CFA
R ASP/oc@$(N), ASP/of@$(N)
S ASP/pc@$( ip=ann501?var=X468&lgix=l<99999999> 1 t=l mn=2 mx=3 sik=* eik=# rik=*)
Beispiel3: Anforderung (1)
http://csv/ansa/servlet/PlayCollect?ip=ann501%3Fvar%3DX468%261gix%3Dl% 6099999999%62&it=l&mn=2&mx=3&sik=*&eik=#&rik=*
Beispiel 4: Request (2) wurde, entspricht dem Beispiel 5, mit der Ausnahme, dass anstelle der Ausdrücke "expr=..." jeweils ";var" zu stehen hat.
4) Die VoiceXML-Seite vpg wird vom Inhaltsserver CSV als HTTP-Response an den Ansageserver VSV zurück gegeben.
5) Seitens des Server VSV wird die Interpretation der Seite vpg begonnen; dabei werden die benötigten Grammar- und Tondateien festgestellt.
6) Diese Dateien werden mittels HTTP-Requests crq wie in Beispiel 6 beispielhaft gezeigt beim Inhaltsserver CSV angefordert; typischerweise erfolgt hierbei eine Anforderung für jeweils eine Datei.
7) Die Dateien grm, wfi werden über HTTP-Responses aufgrund der HTTP-Requests zurück gesendet. Die Fundorte (Dateiadressen), die den Anforderungen bzw. Antworten zugrunde liegen, sind in der VoiceXML-Seite vpg aufgeführt.
8) Die Ansage wird durch den Ansageserver gemäß der VoiceXML- Datei vpg abgespielt; die Eingabe 8' des Teilnehmers wird anhand der Grammardatei grm ausgewertet.
9) Die aus der Eingabe 8" gewonnenen Daten werden über MGCP an die Dienstesteuerung zurück gesendet.
Es sei darauf hingewiesen, dass die besonderen Ausbildungen der hier betrachteten Ausführungsform der Erfindung lediglich beispielhafter Art sind und die Erfindung nicht auf diese Formen einschränken. Insbesondere kann die Verbindung zwischen den Teilnehmern TN1,TN2 auch anderer Art als VoIP sein, nämlich z.B. zur Gänze über analoge und/oder digitale Telekommunikationsnetze realisiert, und die Ansagestation VAS z.B. dem Netz NE1 oder NE2 zugeordnet sein. Beispielsweise kann der Teilnehmer, dem die Ansage abgespielt wird, auch ein IP-Teilnehmer gemäß ITU-T Standard H.323 sein. Auch kann die Realisierung der Ansage- und Eingabedateien auf einem anderen Format beruhen als das einer Markup-Sprache wie VoiceXML.
http: //cv/Announcement-database/X468/FRAGMENTS/fr00009.wav
Beispiel 6: Request (6) <?x l versi on=" l . θ" ?>
<!D0CTYPE vxml PUBLIC '-//Nuance/DTD VoiceXML 1.0b//EN'
'http://to_be_determined.dtd'>
<vxml>
<form id="ann501">
<!--DIAL0G for playing of Charge announcement according to 'INTEGER' structure
WAV-files names are generated according to INFRAGM numbers and appropri - ate language.--> <!--Variant assign ent (var)--> <var name="variant" expr="&apos;X468&apos ; " /> <!--Language assignment (lgix)--> <var name="Lang" expr="&apos ;lanl&apos ; " /> <!--Number of announcement repetitions (it). --> <var name="Repet" expr="l" /> <! --Repeti tion Counter Declaration--> <var name="I" expr="0" />
<! --Parameter 1 declaration (hundred of thousand for pound). "nine" as a sample-->
<var name="parameterl" expr="&apos;9&apos ; " /> <!--Parameter 1 declaration (thousand for pound).. "Ninety nine" as a sample-->
<var name="parameter2" expr="&apos;99&apos ; " /> <! --Parameter 1 declaration (hundred for pound). "nine" as a sample-->
<var name="parameter3" expr="&apos ; 9&apos ; " /> <!--Parameter 1 declaration (units for pound). "Ninety nine" as a sample-->
<var name="parameter4" expr="&apos;99&apos; " /> <! --Parameter 1 declaration (units for pence) . "Ninety nine" as a sample-->
<var name="parameter5" expr="&apos;99&apos ; " /> <!--Varible declaration for the path--> <var name="Path" expr="&apos; http: //csv/Announcement-database/+variant+/FRAGMENTS/&apos ; " />
<--Repetions counter calculation--> <grammar source= http://csv/Announcement-database/+variant+/GRAMMARS/grammar.gsl> <block name="Repeti tions">
<assign name="I" expr="I+l" /> <if cond="I&lt;=Repet">
<if cond="parameterl == &apos ;ΘΘ&apos ; &amp;&amp; parameter2 == &apos;θθ&apos;&amp;&amp; parameter3 == &apos;G0&apos;&amp;&amp; parameter4 == &apos;GΘ&apos;&amp;&amp; Parameters == &apos;Θ0&apos; ">
<audio expr="Path+f r00001.wav" />
<!--This call is free of charge-->
<else />
<audio expr="Path+fr00002.wav" />
<!--This call costs-->
<!--Control of hundred thousand value-->
<if cond="parameterl != &apos ;00&apos; "> <audio expr="Path+&apos;fr000&apos;+parameterl+&apos; .wav&apos;" /> <audio expr="Path+fr00003.wav" /> </if>
<!--Control of thousand value--> <if cond="parameter2 != &apos;θθ&apos; "> <audio expr="Path+&apos;f rθθθ&apos;+parameter2+&apos; .wav&apos; " /> <elseif cond="parameterl != &apos;θ0&apos ; " /> <audio expr="Path+&apos; fr00004.wav" /> </if>
<!--Control of hundred value--> <if cond="parameter3 != &apos ;00&apos; "> <audio expr="Path+&apos;frθθ0&apos;+parameter3+&apos ; .wav&apos; " /> <audio expr='.'Path+fr00003.wav" /> </if>
<!--Control of units value for pound--> <if cond="parameter4 != &apos ;00&apos ; "> <audio expr="Path+fr00004.wav" /> <audio expr="Path+&apos;frθ0θ&apos;+parameter4+&apos; .wav&apos;" /> </if>
<! --announcement "pound"-->
<if cond="parameterl| |parameter2| |parameter3| |parameter4 ! = &apos;00&apos;"> <if cond="parameter5 != &apos ;00&apos; ">
<audio expr="Path+&apos;fr00Θ07.wav&apos ; " /> <!--High pitch of "pound"--> <else />
<audio expr="Path+&apos;fr00008.wav&apos;" /> <!--Low pitch of "pound"--> </1f> </if>
<! --announcement "pence"--> <if cond="parameter5 != &apos ;00&apos ; "> <audio expr="Path+&apos;fr000&apos;+parameter5+&apos; .wav&apos;" /> <audio expr="Path+fr00009.wav" /> </if> </if>
<goto nexti tem="Repeti tions" /> <else /> <exit /> </if> </block> </form> </vxml>
Beispiel 5: Ansagedatei

Claims

Patentansprüche
1. Verfahren zur Durchführung einer akustisch wiedergebbaren Ansage in einem Telekommunikationsnetz, gekennzeichnet durch folgende Schritte:
- Empfangen einer von einer Steuerstelle (SCI, GCl) des Telekommunikationsnetzes gesendeten Anforderung (1) für eine Ansage und Ermitteln Ansagen-spezifischer Parameterwerte
(aid,prv) ,
- Erstellen (3) zumindest einer Ansagendatei (vpg) aus zumindest einer Vorlagedatei (vtm) , die offene Parameter betreffend den Inhalt und/oder die Ausführung einer Ansage enthält, wobei in der Ansagendatei (vpg) die offenen Parameter der Vorlagedatei (en) in Abhängigkeit von den Parameterwerten (prv) aufgelöst werden, und
- Interpretation (5) der zumindest einen Ansagedatei (vpg) als Ansage, wobei die Ansage über das Telekommunikationsnetz ausgegeben wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass gemäß einer Markup- Sprache abgefasste Vorlage- und Ansagedateien verwendet werden, z.B. gemäß der VoiceXML-Sprache.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass vor dem Erstellen der Ansagedatei die hierfür verwendete (n) Vorlagedatei (en) (vtm) aus einer Anzahl von Vorlagedateien in Abhängigkeit von den Parameterwerten (aid) ausgewählt wird (werden) .
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass beim Erstellen der Ansagedatei, sofern die Vorlagedatei (vtm) sich auf eine Eingabe beziehende Befehle enthält, zusätzlich Eingabedateien (grm) für die Interpretation von Eingaben (8') während einer
Ansage erstellt werden.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Eingabedateien (grm) in einem Dateispeicher (GRS) zwischengespeichert werden und von dort bei der Ausführung der betreffenden Eingaben abgerufen werden.
6. Servereinrichtung (CVS) für Ansagedateien, mit einer Schnittstelle zu einer Ansageeinrichtung (VSV) , welche ein Interpretermodul (VBR) für die Interpretation von Ansagedateien als akustisch wiedergebbare Ansagen enthält, und mit einer Präprozessoreinrichtung (PPZ) , welche dazu eingerichtet ist, Ansagen-spezifische Parameterwerte (aid,prv) entgegenzunehmen und ausgehend von offene Parameter betreffend den Inhalt und/oder die Ausführung einer Ansage enthaltende Vorlagedateien (vtm) in Abhängigkeit von den Parameterwerten (prv) Ansagedateien (vpg) zu erstellen, in denen die offenen Parameter der Vorlagedatei (en) aufgelöst sind.
7. Servereinrichtung nach Anspruch 6, gekennzeichnet durch einen Speicher (TMS) für Vorlagedateien, aus dem Vorlagedateien (vtm) in Abhängigkeit von Parameterwerten (aid) auswählbar sind.
8. Servereinrichtung nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass die Präprozessoreinrichtung dazu eingerichtet ist, zu prüfen, ob die Vorlagedatei (vtm) sich auf eine Eingabe beziehende Befehle enthält, und zutreffendenfalls beim Erstellen der Ansagedatei zusätzlich Eingabedateien (grm) für die Interpretation von Eingaben (8') während einer Ansage zu erstellen.
9. Servereinrichtung nach Anspruch 8, gekennzeichnet durch einen Dateispeicher (GRS) zur Zwischenspeicherung der Eingabedateien (grm) .
10. Ansagesystem (VAS) zur Bereitstellung von akustisch wiedergebbaren Ansagen in einem Telekommunikationsnetz, mit einer Schnittstelleneinrichtung (VIF) zur Anbindung an das Telekommunikationsnetz und an eine dem Telekommunikationsnetz zugeordnete Steuerstelle (GCl, SCI), mit einer Speichereinrichtung (CSS) und mit einem Interpretermodul (VBR) für die Interpretation von Ansagedateien als akustisch wiedergebbare Ansagen, gekennzeichnet durch eine Präprozessoreinrichtung (PPZ) ,■ welche dazu eingerichtet ist, Ansagen-spezifische Parameterwerte (aid, prv) entgegenzunehmen und ausgehend von offene Parameter betreffend den Inhalt und/oder die Ausführung einer Ansage enthaltende Vorlagedateien (vtm) in Abhängigkeit von den Parameterwerten (prv) Ansagedateien (vpg) zu erstellen, in denen die offenen Parameter der Vorlagedatei (en) aufgelöst sind.
PCT/DE2002/004029 2001-10-29 2002-10-28 Verfahren und system zum dynamischen generieren von ansageinhalten WO2003039122A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE10153279 2001-10-29
DE10153279.2 2001-10-29
DE10200855A DE10200855A1 (de) 2001-10-29 2002-01-11 Verfahren und System zum dynamischen Generieren von Ansageinhalten
DE10200855.8 2002-01-11

Publications (1)

Publication Number Publication Date
WO2003039122A1 true WO2003039122A1 (de) 2003-05-08

Family

ID=26010477

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/004029 WO2003039122A1 (de) 2001-10-29 2002-10-28 Verfahren und system zum dynamischen generieren von ansageinhalten

Country Status (1)

Country Link
WO (1) WO2003039122A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006067027A1 (de) * 2004-12-21 2006-06-29 Nokia Siemens Networks Gmbh & Co. Kg Verfahren zum dezentralen bereitstellen von mehrsprachigen dialogen mittles sprachunabhängiger definition der dialoge

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5799063A (en) * 1996-08-15 1998-08-25 Talk Web Inc. Communication system and method of providing access to pre-recorded audio messages via the Internet
WO2000005708A1 (en) * 1998-07-24 2000-02-03 Motorola Inc. Voice browser for interactive services and methods thereof
EP1041801A2 (de) * 1999-03-31 2000-10-04 Lucent Technologies Inc. Verfahren des Zur Verfügung stellens von Übergangsfähigkeit auf Web-basierten interaktiven Sprachwartedienstleistungen
WO2000065814A1 (en) * 1999-04-23 2000-11-02 Nuance Communications Object-orientated framework for interactive voice response applications
EP1056268A2 (de) * 1999-05-25 2000-11-29 Lucent Technologies Inc. Verfahren und Gerät zum erzeugen und versenden von strukturierten Sprachpostnachrichten

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5799063A (en) * 1996-08-15 1998-08-25 Talk Web Inc. Communication system and method of providing access to pre-recorded audio messages via the Internet
WO2000005708A1 (en) * 1998-07-24 2000-02-03 Motorola Inc. Voice browser for interactive services and methods thereof
EP1041801A2 (de) * 1999-03-31 2000-10-04 Lucent Technologies Inc. Verfahren des Zur Verfügung stellens von Übergangsfähigkeit auf Web-basierten interaktiven Sprachwartedienstleistungen
WO2000065814A1 (en) * 1999-04-23 2000-11-02 Nuance Communications Object-orientated framework for interactive voice response applications
EP1056268A2 (de) * 1999-05-25 2000-11-29 Lucent Technologies Inc. Verfahren und Gerät zum erzeugen und versenden von strukturierten Sprachpostnachrichten

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Dial-A-Web Browser", RESEARCH DISCLOSURE, vol. 41, no. 412, 1 August 1998 (1998-08-01), Havant, UK, article No. 41288, XP002232872 *
LAVALLEE LIONEL: "Integrating VoiceXML and an Application Server: A Case Study", VOICEXML REVIEW, September 2001 (2001-09-01), XP002232871, Retrieved from the Internet <URL:http://www.voicexmlreview.org/Sep2001/features/integrating_voicexml.html> [retrieved on 20030227] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006067027A1 (de) * 2004-12-21 2006-06-29 Nokia Siemens Networks Gmbh & Co. Kg Verfahren zum dezentralen bereitstellen von mehrsprachigen dialogen mittles sprachunabhängiger definition der dialoge

Similar Documents

Publication Publication Date Title
DE60222093T2 (de) Verfahren, modul, vorrichtung und server zur spracherkennung
DE102009045187B4 (de) System und Verfahren zum Kommunizieren mit Telefonagenten in einem automatisierten Call Center
DE4041273C1 (de)
DE69922872T2 (de) Automatischer Hotelportier mit Spracherkennung
DE69839068T2 (de) System und Verfahren zur automatischen Verarbeitung von Anruf und Datenübertragung
EP1241600A1 (de) Verfahren und Kommunikationssystem zur Generierung von Antwortmeldungen
DE10100725C1 (de) Automatisches Dialogsystem mit Datenbanksprachmodell
DE10208295A1 (de) Verfahren zum Betrieb eines Sprach-Dialogsystems
DE60018349T2 (de) Erzeugung von einem Namenwörterbuch aus aufgezeichneten telephonischen Grüssen für die Spracherkennung
EP1454464A1 (de) System zur umsetzung von textdaten in eine sprachausgabe
DE19632296A1 (de) Verfahren und Vorrichtung zum Vermitteln von Mitfahrgelegenheiten in einem Telekommunikationsnetz
WO2003039122A1 (de) Verfahren und system zum dynamischen generieren von ansageinhalten
EP1251680A1 (de) Sprachgesteuerter Verzeichnisdienst für Verbindung an ein Datennetzwerk
DE10200855A1 (de) Verfahren und System zum dynamischen Generieren von Ansageinhalten
EP1659571A2 (de) Sprachdialogsystem und Verfahren zum Betreiben
DE10050360B4 (de) Verfahren Aktivierung und/oder Deaktivierung von Diensten in einem Vermittlungssystem
EP1164575A2 (de) Ausgabe einer Sprachansage
EP2321952A1 (de) Konferenzeinheit und verfahren zur durchführung einer mehrpunktkommunikation
EP1457029A1 (de) Verfahren zum austausch von informationen mittels sprache über ein paketorientiertes netzwerk
DE19845272A1 (de) Verfahren, Server und Endgerät zur Modifikation von in einem Server gespeicherten Dienstleistungs-Daten
DE10020831A1 (de) Verfahren zum Austauschen von Sprachinformationen und Daten
EP0649240B1 (de) Kommunikationssystem
EP1282295A2 (de) Konvertierungseinrichtung und Konvertierungsverfahren für einen akustischen Zugang zu einem Computernetzwerk
EP1606918B1 (de) Verfahren und vorrichtung zur bereitstellung und effizienten nutzung von ressourcen für das erzeugen und ausgeben von informationen in paketbasierten netzen
DE60211264T2 (de) Adaptieve Navigation in einer Sprachantwortsystem

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase