EP1678936A2 - Verfahren zur aufwandsbeschränkung bei der übertragung von unidirektionalen informationsströmen - Google Patents

Verfahren zur aufwandsbeschränkung bei der übertragung von unidirektionalen informationsströmen

Info

Publication number
EP1678936A2
EP1678936A2 EP04791290A EP04791290A EP1678936A2 EP 1678936 A2 EP1678936 A2 EP 1678936A2 EP 04791290 A EP04791290 A EP 04791290A EP 04791290 A EP04791290 A EP 04791290A EP 1678936 A2 EP1678936 A2 EP 1678936A2
Authority
EP
European Patent Office
Prior art keywords
communication device
ivr
user data
transmitted
communication
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP04791290A
Other languages
English (en)
French (fr)
Inventor
Mathias Franz
Detlev Freund
Norbert LÖBIG
Johannes SCHÖPF
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
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
Application filed by Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Publication of EP1678936A2 publication Critical patent/EP1678936A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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

Definitions

  • the invention relates to a method for reducing the complexity of processing user data transmitted in the direction of a communication device in cases in which a bidirectional connection between the communication device and a communication partner instance is set up as part of a service, although the service does not require any user data transmission to the communication device ,
  • the invention lies in the field of voice and data communication and particularly affects aspects of switching technology.
  • Pure information output systems eg pure announcement systems.
  • information output systems which only provide the output of information (for example voice information) and which may not be controllable by externally supplied information (such as systems for interactive voice dialog)
  • the resources for processing information transmitted to the system can be reduced.
  • Pure distribution systems Distribution systems are often limited to the forwarding or relaying of information or user data. Resources for the interpretation or processing of user data can be provided to a reduced extent.
  • the saving measures described above are limited by the fact that there must be compatibility when communicating with other devices or end devices.
  • There are communication instances e.g. end devices, switching devices or gateways in which a bidirectional connection is provided as part of a communication process, regardless of whether user data is actually being sent to the communication partner instance.
  • resources for processing information transmitted by the communication partner instance must be provided by information output systems or communication distribution systems in order to enable a bidirectional connection.
  • An example of such a scenario is the information exchange between a pure announcement system and a terminal, in which only a bidirectional connection is supported by the terminal.
  • relevant information is only transmitted in one direction (from the announcement system to the terminal)
  • user data transmission also takes place in the other direction, which consists, for example, in the transmission of background noise picked up by a microphone of the terminal.
  • the user data stream or bearer stream transmitted from the terminal to the announcement system is then irrelevant for the service, but requires processing resources on the part of the announcement system.
  • the protocols used provide that information is sent in both directions, which contains statistical statements about the quality of the connection. This information is used, for example, to regulate the transmission rate.
  • a participating communication device must therefore have means for generating this information.
  • RTP real time protocol
  • RTCP real time control protocol
  • Protocol stack outputs voice information to a terminal device that only supports bidirectional RTP connections, statistical information about the connection is transmitted in both directions using the RTCP protocol.
  • the object of the invention is to make it possible to reduce the complexity of communication devices.
  • the invention is based on the observation that for communication devices which generally or for certain services do not provide any useful data transmission to a communication partner instance, in cases in which a bidirectional connection to the partner instance is nevertheless established, for example because the communication partner instance only has bidirectional connections to the
  • the protocol used supports the processing effort that can be reduced by the user data transmitted by the communication partner instance by at least a part of this being used by the communication partner instance in the direction of the communication device transmitted user data are discarded.
  • the communication partner instance can be given, for example, by a terminal or a gateway.
  • the invention has the advantage of greater resource efficiency compared to conventional systems.
  • the processing effort is reduced by discarding transmitted user data that are irrelevant to the service. Any irrelevant background noise transmitted during a voice connection is not fully evaluated in the communication device.
  • Part of the hardware or software resources that are conventionally provided in the communication device for processing useful data transmitted to the communication device can be saved. This can relate to expensive special hardware, such as DSPs (DSP: digital signaling processor) or ASICs (ASIC: application specific integrated circuit).
  • the invention can be used, for example, in packet-oriented networks, via which user data are transmitted as user data packets in the direction of the communication device.
  • the packages can be discarded e.g. Realize in the following two ways:
  • a router upstream of the communication device discards the user data transmitted to the communication device.
  • Incoming data packets are filtered in the communication device, for example using the UDP port addresses (UDP: user datagram protocol), and user data packets that were sent by the communication partner instance are the discarded.
  • UDP user datagram protocol
  • This filtering out of the user data not relevant for the service can be carried out on the lower layers of the protocol stack. Processing on the upper layers of the communication protocol or evaluation or interpretation of transmitted user data is not necessary, so that no resources have to be provided for this.
  • the user data packets are transmitted, for example, using the RTP protocol.
  • the RTCP protocol is used to control RTP connections.
  • statistical information is transmitted between the communication entities, which often relates to the transmission quality of the user data transmissions of the communication entities.
  • the generation of such statistical information or generally control information on the connection quality requires the evaluation of the transmitted user data.
  • the present invention provides that a portion of the useful data is discarded for the cases mentioned, that is to say it is not evaluated for the transmission quality.
  • control partner instance is not prompted for undesired reactions, in the extreme case of the termination of the bidirectional connection, because of missing or misleading messages or information about the connection established to the communication device.
  • the communication device sends information or messages to the communication partner instance, which simulates the proper functioning of the user data transmission from the control partner instance to the communication device.
  • a known value range can be used for the control information, which corresponds to interference-free useful data transmission. It is also possible that a small part of the user data is not discarded, but instead used for the calculation of statistical information or control information. evaluates and extrapolates the results obtained for the entire amount of user data.
  • FIG. 1 A communication device and a communication partner instance that communicate with one another, with useful data transmitted from the communication partner instance to the communication device being filtered out by a router.
  • FIG. 2 A communication device and a communication partner instance in a communication relationship, user data sent from the communication partner instance to the communication device being filtered out and rejected in the communication device.
  • FIG. 1 shows a router R which filters out useful data transmitted to the communication device IVR with the aid of a filter F, so that it does not reach the communication device IVR.
  • this filter function is carried out by the communication device IVR itself, which uses a filter F to filter out and discard useful data transmitted by the communication partner instance KPI, which thus need not be processed by higher protocol layers.
  • the communication device IVR is, for example, a software-based VoIP (VoIP: voice over IP) announcement system based on the RTP and the RTCP protocol.
  • VoIP voice over IP
  • an announcement system is described as an example of how to work with unidirectionally operated channels instead of bidirectionally operated RTP / RTCP channels.
  • an upstream router discards the RTP packets in the direction of the announcement system, so that, despite bidirectional switching, the announcement system is not subjected to an RTP load.
  • the call controller controlling the connection or the remote end point connects a symmetrical RTP stream through the IP network to the announcement system.
  • a static filter is set up, which recognizes and discards all IP packets leading to the announcement system using the RTP protocol based on the ÜDP (user data protocol) ports used by these protocols.
  • ÜDP user data protocol
  • RTCP sender reports are sent as provided in RFC 1889 (RFC: request for cornments).
  • RFC request for cornments
  • the standard already provides that these are sent out relatively rarely, so that it does not require a great deal of computing time.
  • the RTCP filter can therefore forward packets to the RTCP protocol protocol stack of the announcement system.
  • a perfect functioning of a bidirectional connection can be simulated at the level of the RTCP protocol.
  • the RTCP protocol provides for the optional sending of so-called receiver reports from the announcement system to the remote user.
  • a bearer or user data stream was physically switched through the IP network, one can try to evaluate the voice streams or voice activity messages picked up by the remote microphone and transmitted via the communication partner instance in order to give the remote user, or his bearer treatment, to pretend a duplex stream, ie a bidirectional connection.
  • the reception report can contain the following parameters (according to RFC 1889):
  • SSRC Synchronization source
  • the RTCP statistics function Controlled via a suitable, time-controlled dynamic filter above the IP stack (which is sensitized to RTP port addresses), the RTCP statistics function only receives RTP packets over a limited period of time (e.g. the duration of an announcement call), e.g. over several equally distributed 100 ms Intervals of the announcement connection lasting an average of 10 seconds were delivered.
  • the RTCP ports are basically open here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Meter Arrangements (AREA)

Abstract

Bei Informationsausgabe- und Verteildiensten sind häufig zu der entsprechenden Kommunikationsvorrichtung (d.h. Informationsausgabesystem bzw. dem Verteilsystem) übertragene Nutzdatenströme für den Dienst irrelevant. Trotzdem werden in vielen Fällen aus Kompatibilitätsgründen Ressourcen für die Bearbeitung eingehender Nutzdatenströme in der Kommunikationsvorrichtung (IVR) bereitgestellt. Die Erfindung erlaubt in diesen Fällen eine Aufwandsreduzierung in der Kommunikationsvorrichtung (IVR). Erfindungsgemäss wird zur Reduzierung des Aufwands der Bearbeitung von in Richtung der Kommunikationsvorrichtung (IVR) übertragenen Nutzdaten zumindest ein Teil der Nutzdaten vor Durchführung von im Rahmen einer Bearbeitung von Nutzdaten vorgesehenen Arbeitsschritten verworfen.

Description

Beschreibung
Verfahren zur Aufwandsbeschränkung bei der Übertragung von unidirektionalen Informationsströmen
Die Erfindung betrifft ein Verfahren zur Reduzierung des Aufwands der Bearbeitung von in Richtung einer Kommunikations- Vorrichtung übertragenen Nutzdaten in Fällen, bei denen im Rahmen eines Dienstes eine bidirektionale Verbindung zwischen der Kommunikationsvorrichtung und einer Kommunikationspartnerinstanz eingerichtet wird, obwohl der Dienst keine Nutzdatenübertragung zu der Kommunikationsvorrichtung erfordert.
Die Erfindung liegt auf dem Gebiet der Sprach- und Datenkom- munikation und berührt insbesondere Aspekte der Vermittlungstechnik.
In der Kommunikationstechnik gibt es ein stetiges Streben nach Ressourceneffizienz. Dabei spielen Einsparungen bei Kom- munikationsvorrichtungen zum Vermitteln und Verteilen von Nutzdaten eine wichtige Rolle. Bei der Reduzierung des Aufwands und der Komplexität derartiger Einrichtungen ist jedoch zu berücksichtigen, dass Standards einzuhalten und die Kompatibilität zu anderen Kommunikationsvorrichtungen gewahrt wer- den soll. Diese Anforderungen stehen der Reduktion der eingesetzten Mittel bzw. Ressourcen häufig im Wege.
Ein wichtiges Beispiel für Kommunikationsvorrichtungen mit einem Potential für Einsparungen sind Vorrichtungen, deren Funktionalität keine Bearbeitung von eingehenden Nutzdaten erfordert. Beispiele für derartige Kommunikationsvorrichtungen sind:
• Reine Informationsausgabesysteme, z.B. reine Ansagensysteme. Bei Informationsausgabesystemen, welche nur die Ausga- be von Informationen (z.B. Sprachinformationen) vorsehen und nicht evtl. durch extern zugeführte Informationen steuerbar sind (wie z.B. Systeme zum interaktiven Sprach- dialog) , können die Ressourcen zur Bearbeitung von zu dem System übermittelten Informationen reduziert werden. • Reine Verteilsysteme. Verteilsysteme beschränken sich häufig auf das Weiterleiten bzw. Weitervermitteln von Infor- mationen bzw. Nutzdaten. Ressourcen für die Interpretation bzw. Bearbeitung von Nutzdaten können in reduziertem Umfang vorgesehen werden.
Die oben beschriebenen Einsparungsmaßnahmen sind dadurch be- grenzt, dass Kompatibilität bei der Kommunikation mit anderen Vorrichtungen bzw. Endgeräten gegeben sein muss. So gibt es Kommunikationsinstanzen (z.B. Endgeräte, Vermittlungsvorrichtungen oder Gateways) , bei welchen im Rahmen eines Kommunikationsvorgangs eine bidirektionale Verbindung vorgesehen ist, unabhängig davon, ob tatsächlich Nutzdaten zu der Kommunikationspartnerinstanz gesendet werden. Für Verbindungen zur Nutzdatenübermittlung zu einer derartigen Kommunikationsinstanz müssen von Informationsausgabesystemen bzw. Kommunikationsverteilsystemen Ressourcen für die Bearbeitung von der Kommunikationspartnerinstanz übermittelten Informationen vorgesehen werden, um eine bidirektionale Verbindung zu ermöglichen.
Ein Beispiel für eine derartiges Szenario ist der Informati- onsaustausch zwischen einem reinen Ansagesystem und einem Endgerät, bei dem von dem Endgerät nur eine bidirektionale Verbindung unterstützt wird. Obwohl nur in einer Richtung (von dem Ansagesystem zu dem Endgerät) relevante Informationen übertragen werden, kommt auch in der anderen Richtung ei- ne Nutzdatenübertragung zustande, die z.B. in der Übertragung von von einem Mikrophon des Endgerätes aufgenommenen Hintergrundgeräuschen besteht. Der von dem Endgerät zu dem Ansagesystem übertragene Nutzdatenstrom bzw. Bearer-Strom ist dann für den Dienst irrelevant, erfordert aber Bearbeitungsres- sourcen auf Seiten des Ansagesystems. Zudem wird häufig bei einer bidirektionalen Verbindung von den verwendeten Protokollen vorgesehen, dass Informationen in beide Richtungen gesendet werden, welche statistische Aussagen über die Qualität der Verbindung enthalten. Diese Infor- mationen werden z.B. dazu verwendet, die Senderate zu regulieren. Eine beteiligte Kommunikationsvorrichtung muss daher über Mittel zur Generierung dieser Informationen verfügen.
Ein wichtiges Protokoll, bei dem die oben beschriebene Situa- tion vorkommen kann, ist das RTP (real time protocol) Protokoll, welches in Verbindung mit dem RTCP (real time control protocol) verwendet wird. Das RTP Protokoll ermöglicht die Übertragung von Sprache als Nutzdaten bzw. Bearer. Die Übertragung des Bearers wird durch das RTCP Protokoll gesteuert. Wenn beispielsweise ein Ansagesystem mittels dem RTP/RTCP
Protokollstapel Sprachinformationen an ein Endgerät ausgibt, welches nur bidirektionale RTP Verbindungen unterstützt, werden mittels des RTCP Protokolls statistische Informationen über die Verbindung in beiden Richtungen übermittelt.
Die Erfindung hat zur Aufgabe, eine Aufwandsreduzierung bei Kommunikationsvorrichtungen zu ermöglichen.
Die Aufgabe wird durch die Gegenstände der unabhängigen An- sprüche gelöst.
Die Erfindung beruht auf der Beobachtung, dass für Kommunikationsvorrichtungen, welche generell oder für bestimmte Dienste keine Nutzdatenübertragung an eine Kommunikationspartner- instanz vorsehen, in Fällen, in denen trotzdem eine bidirektionale Verbindung zu der Partnerinstanz aufgebaut wird, beispielsweise weil die Kommunikationspartnerinstanz nur bidirektionale Verbindungen mit dem verwendeten Protokoll unterstützt, der Aufwand bei der Bearbeitung, der von der Kommuni- kationspartnerinstanz übertragenen Nutzdaten reduziert werden kann, indem zumindest ein Teil dieser von der Kommunikations- partnerinstanz in Richtung der Kommunikationsvorrichtung ü- bertragenen Nutzdaten verworfen werden.
Beispiele für Vorrichtungen bzw. Dienste, für die in der Re- gel nur Nutzdatenübertragung in einer Richtung, d.h. unidi- rektional vorgesehen ist, sind Informationsausgabesysteme (z.B. Ansagesysteme) und Verteilsysteme bzw. Informationsausgabedienste (z.B. Ansagedienste) und Verteildienste. Die Kommunikationspartnerinstanz kann beispielsweise durch ein End- gerät oder ein Gateway gegeben sein.
Die Erfindung hat den Vorteil von im Vergleich zur herkömmlichen Systemen größerer Ressourceneffizienz. Der Bearbeitungsaufwand wird reduziert, indem übertragene Nutzdaten, die für den Dienst irrelevant sind, verworfen werden. Ein eventuell bei einer Sprachverbindung übertragenes irrelevantes Hintergrundgeräusch wird in der Kommunikationsvorrichtung nicht vollständig ausgewertet. Ein Teil der Hardware bzw. Softwareressourcen, die in der Kommunikationsvorrichtung herkömmlich zur Bearbeitung von an die KommunikationsVorrichtung übertragenen Nutzdaten vorgesehen sind, können eingespart werden. Dies kann teure spezielle Hardware, wie DSPs (DSP: digital signalling processor) oder ASICs (ASIC: application specific integrated circuit) betreffen.
Die Erfindung ist beispielsweise anwendbar in paketorientierten Netzen, über welche Nutzdaten als Nutzdatenpakete in Richtung der KommunikationsVorrichtung übertragen werden. In diesem Fall lässt sich der Verwurf der Pakete z.B. auf fol- gende zwei Weisen realisieren:
• Ein der Kommunikationsvorrichtung vorgelagerter Router verwirft die zu der Kommunikationsvorrichtung übertragenen Nutzdaten.
• In der Kommunikationsvorrichtung werden eintreffende Da- tenpakete gefiltert, z.B. anhand der UDP-Portadressen (UDP: user datagram protocol), und Nutzdatenpakete, welche von der Kommunikationspartnerinstanz gesendet wurden, wer- den verworfen. Dieses Herausfiltern der nicht für den Dienst relevanten Nutzdaten kann auf den unteren Schichten des Protokollstapels vorgenommen werden. Eine Bearbeitung auf den oberen Schichten des Kommunikationsprotokolls oder eine Auswertung bzw. Interpretation übermittelter Nutzdaten ist nicht erforderlich, so dass dafür keine Ressourcen vorgesehen werden müssen.
Die Nutzdatenpakete werden im Falle von Echtzeitverkehr bei- spielsweise mittels des RTP-Protokolls übertragen. Für die Steuerung von RTP-Verbindungen wird das RTCP-Protokoll verwendet. Gemäß dem RTCP-Protokoll werden statistische Informationen zwischen den Kommunikationsinstanzen übertragen, welche sich häufig auf die Übertragungsqualität der Nutzdaten- übertragen der Kommunikationsinstanzen bezieht. Herkömmlich erfordert die Generierung solcher statistischer Informationen oder generell von Kontrollinformationen zur Verbindungsqualität die Auswertung der übersendeten Nutzdaten. Die vorliegende Erfindung sieht allerdings vor, dass für die angesproche- nen Fälle ein Teil der Nutzdaten verworfen, also nicht auf die Übertragungsqualität hin ausgewertet werden. Entsprechend einer vorteilhaften Weiterbildung kann verhindert werden, dass die Kontrollpartnerinstanz wegen ausbleibender oder irreführender Meldungen bzw. Informationen über die zur Kommu- nikationsvorrichtung aufgebauten Verbindung zu ungewünschten Reaktionen - im Extremfall der Beendigung der bidirektionalen Verbindung - veranlasst wird. Dabei sendet die Kommunikationsvorrichtung Informationen bzw. Meldungen an die Kommunikationspartnerinstanz, die ein einwandfreies Funktionieren der Nutzdatenübertragung von der Kontrollpartnerinstanz zu der Kommunikationsvorrichtung simuliert. Dabei kann z.B. ein bekannter Wertebereich für die Kontrollinformationen benutzt werden, welcher einer störungsfreien Nutzdatenübertragung entspricht. Weiter ist es möglich, dass man einen kleinen Teil der Nutzdaten nicht verwirft, sondern für die Berechnung statistischer Informationen bzw. Kontrollinformationen aus- wertet und die erhaltenen Ergebnisse für die gesamte Menge an Nutzdaten extrapoliert.
Die Erfindung wird im Folgenden im Rahmen eines Ausführungs- beiSpiels anhand von Figuren näher erläutert. Es zeigen:
Figur 1 : Eine Kommunikationsvorrichtung und eine Kommunikationspartnerinstanz, die miteinander kommunizieren, wobei von der Kommunikationspartnerinstanz zu der Kommunikationsvorrichtung übertragenen Nutzdaten von einem Router herausgefiltert werden.
Figur 2 : Eine Kommunikationsvorrichtung und eine Kommunikationspartnerinstanz in Kommunikationsbeziehung, wo- bei von der Kommunikationspartnerinstanz an die Kommunikationsvorrichtung gesendete Nutzdaten in der Kommunikationsvorrichtung herausgefiltert und verworfen werden.
Beide Figuren zeigen eine Kommunikationsvorrichtung IVR (IVR: Interactive Voice Response) und eine Kommunikationspartnerinstanz KPI, welche über eine bidirektionale Verbindung mittels des RTP-Protokolls Nutzdaten miteinander austauschen. Gesteuert bzw. kontrolliert werden diese Verbindungen mittels des RTCP-Protokolls. In Figur 1 ist ein Router R gezeigt, der mit Hilfe eines Filters F an die Kommunikationsvorrichtung IVR übertragene Nutzdaten herausfiltert, so dass diese nicht zu der Kommunikationsvorrichtung IVR gelangen. In Figur 2 wird diese Filterfunktion von der Kommunikationsvorrichtung IVR selber vorgenommen, welche mit Hilfe eines Filters F von der Kommunikationspartnerinstanz KPI übertragene Nutzdaten herausfiltert und verwirft, welche so nicht durch höhere Protokollschichten bearbeitet werden müssen.
Bei der Kommunikationsvorrichtung IVR handelt es sich beispielsweise um ein Software-basiertes VoIP (VoIP: voice over IP) Ansagesystem auf Basis des RTP und des RTCP Protokolls. In Folgenden wird beispielhaft für ein Ansagesystem beschrieben, wie man statt bidirektional betriebener RTP/RTCP Kanäle mit unidirektional betriebenen Kanälen arbeiten kann.
Bei dem ersten Beispiel entsprechend Fig. 1 verwirft ein vorgelagerter Router die RTP Pakete in Richtung Ansagesystem, so dass trotz bidirektionaler Durchschaltung das Ansagesystem nicht mit RTP-Last beaufschlagt wird.
Im Fall der Behandlung der Nutzdaten in dem Ansagesystem (Beispiel entsprechend Fig. 2) schaltet der die Verbindung steuernde Call Controller oder der entfernte Endpunkt einen symmetrischen RTP Strom durch das IP Netz zum Ansagesystem durch. Oberhalb des IP Stacks, d.h. des IP Protokollstapels im Ansagesystem, wird ein statischer Filter eingerichtet, der alle zum Ansagesystem führenden mittels des RTP Protokolls übertragenen IP Pakete anhand der durch diese Protokolle verwendeten ÜDP (user datagra m protocol) Ports erkennt und ver- wirft. Die höheren Protokoll Layer, die rechenzeitaufwendigere Aufgaben für diese Pakete durchführen müssten, werden dadurch nicht mehr belastet und müssen nur noch ausgehende Datenströme behandeln.
Da in einem Software-basierten Ansagesystem ein sehr hoher Anteil der Performance auf die Behandlung von RTP Protokollabläufe entfällt, kann das frei werdende Rechenzeit Budget nun z.B. zur Behandlung weiterer Ansage Ports verwendet werden .
RTCP sender reports werden wie in RFC 1889 (RFC: request for cornments) vorgesehen ausgesendet. Der Standard sieht bereits vor, dass diese relativ selten ausgesendet werden, so dass es keines großen Rechenzeitaufwandes bedarf. Daher kann der Fil- ter RTCP Pakete an den RTCP Rrotokollstapel des Ansagesystems weiterleiten. Entsprechend einer Weiterbildung des Anmeldegegenstands kann auf Ebene des RTCP Protokolls ein einwandfreies Funktionieren einer bidirektionalen Verbindung simuliert werden. Das RTCP Protokoll sieht das optionale Aussenden von sogenannten Re- ceiver Reports vom Ansagesystem zum entfernten Anwender vor. Da im Ausführungsbeispiel ein Bearer bzw. Nutzdaten Strom physikalisch durch das IP Netz geschaltet wurde, kann man versuchen, die vom entfernten Mikrofon aufgenommenen und via der Kommunikationspartnerinstanz übertragenen Sprachströme oder Voice Activity Meldungen zu bewerten, um dem entfernten Anwender, bzw. dessen Bearer Behandlung, einen Duplex Stream, d.h. eine bidirektionale Verbindung, vorzuspiegeln.
Damit das Ziel der Aufwandsreduzierung, die durch Ausfüh- rungsbeispiel 1 erreicht wird, nicht konterkariert wird, ist es sinnvoll, auf eine kontinuierliche Berechnung der RTCP Statistiken auf Basis aller empfangenen RTP Pakete zu verzichten. Folgende Lösungsansätze zur Reduzierung des Aufwands bei der Berechnung der RTCP Statistiken können beschriften werden:
a) Aussenden eines default Reception Reports
Da ein hier beschriebenes Ansage- oder Verteilsystem nicht von der Qualität des empfangenen Stroms abhängig ist, können in den Report erfahrungsgemäß akzeptable Standardwerte eingetragen werden. Sollte ein Network Operator diese auswerten bzw. interpretieren, muss ihm der Umstand, dass speziell diese Reports nicht aussagekräftig sind, lediglich im Rahmen der Definition der Standardwerte bewusst sein. Damit wird sichergestellt, dass das entfernte Bearer Treatment keine ungewollten Gegenmaßnahmen einleitet (z.B. die Senderate reduziert oder Fehler Reports generiert) . Der Reception Report kann folgende Parameter (entsprechend RFC 1889) enthalten:
• SSRC (Synchronization source) der sendenden Quelle (kann aus beliebigen empfangenen RTP Paketen, z.B. mittels ei- nes RTP Sniffers bzw. Filters, welcher wenigstens zu Beginn des Rufes/der Session einige Pakete auswertet, ermittelt werden oder aus dem letzten empfangenen Sender Report ermittelt werden) • Lost Fraction : hier wird 256 eingetragen, was einem i- dealem Empfang entspricht. • Cumulated number of lost packages : hier wird 0 oder ein sehr geringer Wert eingetragen • Highest received sequence number: die Anzahl der Sequen- ce Number Cycles und der Highest Sequence Number Received wird aus einer Rundung einer algorithmischen Berechnung aus
- der Zeit seit dem letzten Reception Report (alternativ kann der Beginn der Bearer Durchschaltung zugrunde gelegt werden) - dem Codec Type und seiner Bandbreite und - den verwendeten Paketisierungsgrössen (Ergebnisse der Codec Negotiation) mittels der zu erwartenden RTP Paketanzahl ermittelt. Diese Parameter sind bei Ansagesystemen pro Ruf/Session stabil und es ist daher eine derartige Berechnung / Folge von Divisionen möglich. • Interarrival Jitter: hier wird ein unverdächtiger Wert, der 1 ms entspricht, eingetragen. • Last (arrived) SR: der Zeitstempel des letzten Sendereports wird von der RTCP Statistik Funktion für Sender Reports übernommen. • Delay since last (arrived) SR: die im letzten Sendereport eingetragene Verzögerung wird von der RTCP Statistik Funktion für Sender Reports übernommen.
b) Reduktion der Anzahl der RTP Pakete, die von der RTCP Sta- tistik Funktion bearbeitet werden muss Kontrolliert über einen geeigneten, zeitlich gesteuerten dynamischen Filter oberhalb des IP Stacks (der auf RTP Port Adressen sensibilisiert ist) , werden der RTCP Statistik Funktion nur RTP Pakete über einen beschränkten Zeitabschnitt (z.B. die Dauer eines Ansage-Rufs), z.B. über mehrere gleichverteilte 100 ms Intervalle der im Mittel 10 Sekunden lang dauernden Ansageverbindung zugestellt. Die RTCP ports sind hier prinzipiell offen.
Hier kann im Wesentlichen eine kommerzielle RTCP Statistik wiederverwendet werden, die eine längere Messung als tatsächlich erfolgt vortäuscht. Der Parameter "Highest Received Sequence Number" muss aber wie unter a) approximativ berechnet werden. Für den "Interarrival Jitter und Lost Fraction" Parameter können dagegen die aus der 100 ms Messung erzeugten Werte als die , realen' Messwerte in den Reception Report eingetragen werden. Der Parameter "Cumulated number of lost packages" muss ebenfalls extrapoliert werden.
Geht man z.B. von 1 Sekunde dauernden Intervallen für das Aussenden der Reception Reports aus und misst man darin jeweils nur 100 ms, so wäre der zu sendende Wert um den Faktor 10 zu multiplizieren. Man trifft hier die Annahme einer Gleichverteilung der Paketverluste über die Rufdauer.

Claims

Patentansprüche
1. Verfahren zur Reduzierung des Auf ands der Bearbeitung von in Richtung einer Kommunikationsvorrichtung (IVR) übertrage- nen Nutzdaten in Fällen, bei denen im Rahmen eines Dienstes eine bidirektionale Verbindung zwischen der Kommunikationsvorrichtung (IVR) und einer Kommunikationspartnerinstanz (KPI) eingerichtet wird, obwohl der Dienst keine Nutzdatenübertragung zu der Kommunikationsvorrichtung (IVR) erfordert, demzufolge zumindest ein Teil der Nutzdaten vor Durchführung zumindest eines Teils der im Rahmen einer Bearbeitung von Nutzdaten vorgesehenen Arbeitsschritten verworfen wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Kommunikationsvorrichtung (IVR) durch ein Informationsausgabesystem oder ein Verteilsystem gegeben ist.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikationspartnerinstanz (KPI) durch ein Endgerät o- der ein Gateway gegeben ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Nutzdaten als Nutzdatenpakete über ein paketorientiertes Netz in Richtung der Kommunikationsvorrichtung (IVR) übertragen werden.
5. Verfahren nach Anspruch 4 , dadurch gekennzeichnet , das s in einem der Kommunikationsvorrichtung (IVR) vorgelagerten
Router (R) zumindest ein Teil der Nutzdatenpakete verworfen werden .
6. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass bei der Kommunikationsvorrichtung (IVR) ankommende Datenpakete gefiltert werden und zumindest ein Teil der von der Kommu- nikationspartnerinstanz (KPI) übertragenen Nutzdatenpakete verworfen werden.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die von der Kommunikationspartnerinstanz (KPI) übertragenen Nutzdatenpakete anhand ihrer Port Adressen identifiziert und herausgefiltert werden.
8. Verfahren nach einem der vorhergehenden Ansprüche 4 bis 7, dadurch gekennzeichnet, dass die Nutzdatenpakete mittels des RTP Protokolls übertragen werden.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von der Kommunikationsvorrichtung (IVR) an die Kommunikationspartnerinstanz (KPI) Informationen übertragen werden, welche eine einwandfreie Übertragung der Nutzdaten von der von der Kommunikationspartnerinstanz (KPI) an die Kommunikations- Vorrichtung (IVR) simulieren.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Informationen die Übertragungsqualität der Nutzdatenüber- tragung von der Kommunikationspartnerinstanz (KPI) zu der Kommunikationsvorrichtung (IVR) betreffen.
11. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass die Informationen mittels des RTCP Protokolls übertragen werden.
12. Kommunikationssystem (IVR) zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 11, gekennzeichnet durch einen Filter zur Identifizierung von von der Ko munikations- partnerinstanz (KPI) zu der Kommunikationsvorrichtung (IVR) übertragenen Nutzdaten.
13. Router (R) zur Durchführung eines Verfahren nach einem der Ansprüche 5 bis 11 gekennzeichnet durch
Mittel zur Verwerfung von von der Kommunikationspartnerinstanz (KPI) zu der Kommunikationsvorrichtung (IVR) übertragenen Nutzdatenpaketen.
EP04791290A 2003-10-29 2004-10-22 Verfahren zur aufwandsbeschränkung bei der übertragung von unidirektionalen informationsströmen Withdrawn EP1678936A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10350353A DE10350353A1 (de) 2003-10-29 2003-10-29 Verfahren zur Aufwandsbeschränkung bei der Übertragung von unidirektionalen Informationsströmen
PCT/EP2004/052630 WO2005043813A2 (de) 2003-10-29 2004-10-22 Verfahren zur aufwandsbeschränkung bei der übertragung von unidirektionalen informationsströmen

Publications (1)

Publication Number Publication Date
EP1678936A2 true EP1678936A2 (de) 2006-07-12

Family

ID=34529843

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04791290A Withdrawn EP1678936A2 (de) 2003-10-29 2004-10-22 Verfahren zur aufwandsbeschränkung bei der übertragung von unidirektionalen informationsströmen

Country Status (5)

Country Link
US (1) US8306194B2 (de)
EP (1) EP1678936A2 (de)
CN (1) CN1875610B (de)
DE (1) DE10350353A1 (de)
WO (1) WO2005043813A2 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10350353A1 (de) * 2003-10-29 2005-06-02 Siemens Ag Verfahren zur Aufwandsbeschränkung bei der Übertragung von unidirektionalen Informationsströmen
US8477759B2 (en) * 2005-09-30 2013-07-02 Qualcomm Incorporated Filtering of malformed data packets in wireless communication
CN101610328A (zh) * 2009-06-19 2009-12-23 中兴通讯股份有限公司 一种voip媒体网关获取语音资源的方法及系统
GB201520380D0 (en) * 2015-11-19 2016-01-06 Qinetiq Ltd A data hub for a cross-domain communication system
US11113385B2 (en) * 2018-12-21 2021-09-07 Paypal, Inc. Communicating trace information between security zones

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4975828A (en) * 1987-08-05 1990-12-04 Cirrus Logic, Inc. Multi-channel data communications controller
US5793843A (en) * 1989-10-31 1998-08-11 Intelligence Technology Corporation Method and apparatus for transmission of data and voice
US5276681A (en) * 1992-06-25 1994-01-04 Starlight Networks Process for fair and prioritized access to limited output buffers in a multi-port switch
US5457687A (en) * 1993-09-02 1995-10-10 Network Equipment Technologies, Inc. Method and apparatus for backward explicit congestion notification (BECN) in an ATM network
US5862208A (en) * 1994-02-16 1999-01-19 Priority Call Management, Inc. Method and system for enabling a party to change terminals during a call
US5706279A (en) * 1995-03-24 1998-01-06 U S West Technologies, Inc. Methods and systems for managing packet flow into a fast packet switching network
GB9618128D0 (en) * 1996-08-30 1996-10-09 Sgs Thomson Microelectronics Improvements in or relating to an ATM switch
US5953338A (en) * 1996-12-13 1999-09-14 Northern Telecom Limited Dynamic control processes and systems for asynchronous transfer mode networks
US6366651B1 (en) * 1998-01-21 2002-04-02 Avaya Technology Corp. Communication device having capability to convert between voice and text message
US6405033B1 (en) * 1998-07-29 2002-06-11 Track Communications, Inc. System and method for routing a call using a communications network
US6445682B1 (en) * 1998-10-06 2002-09-03 Vertical Networks, Inc. Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet buses and methods for performing telephony and data functions using the same
TW420917B (en) * 1998-11-10 2001-02-01 Ibm Method and system for reducing telephone costs for calls to service providers
US6426944B1 (en) * 1998-12-30 2002-07-30 At&T Corp Method and apparatus for controlling data messages across a fast packet network
US6735193B1 (en) * 1999-10-28 2004-05-11 Avaya Technology Corp. Method and apparatus for suppression of packets during silence periods in a packet telephony system
US7257641B1 (en) * 2000-03-30 2007-08-14 Microsoft Corporation Multipoint processing unit
EP1421819B1 (de) * 2001-08-28 2006-06-28 Telefonaktiebolaget LM Ericsson (publ) Multicast gruppenverwaltung in telekommunikationsnetzen
SE524599C2 (sv) * 2002-01-18 2004-08-31 Ericsson Telefon Ab L M Metod, system och datorprogramprodukt för att anordna tjänstekvalitet QoS
US7499446B1 (en) * 2002-04-29 2009-03-03 Cisco Technology, Inc. Removing jitter in RTP streaming media streams
US20070053303A1 (en) * 2005-09-08 2007-03-08 Acterna Llc Transmission Quality Monitoring For Multimedia Streams
US8694677B2 (en) * 2002-07-30 2014-04-08 Nippon Telegraph And Telephone Corporation Retry communication control method and system
DE10350353A1 (de) * 2003-10-29 2005-06-02 Siemens Ag Verfahren zur Aufwandsbeschränkung bei der Übertragung von unidirektionalen Informationsströmen
US7822018B2 (en) * 2006-03-31 2010-10-26 Verint Americas Inc. Duplicate media stream
JP5168283B2 (ja) * 2007-08-20 2013-03-21 富士通株式会社 映像品質監視方法及び配信サーバ及びクライアント
CN101364999B (zh) * 2008-09-18 2012-07-04 华为技术有限公司 一种基于流的服务质量处理的方法、设备及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005043813A2 *

Also Published As

Publication number Publication date
CN1875610A (zh) 2006-12-06
US8306194B2 (en) 2012-11-06
WO2005043813A3 (de) 2005-08-25
DE10350353A1 (de) 2005-06-02
US20070081524A1 (en) 2007-04-12
WO2005043813A2 (de) 2005-05-12
CN1875610B (zh) 2010-11-03

Similar Documents

Publication Publication Date Title
EP1345395B1 (de) Verfahren zum Abhören von Kommunikationsverbindungen
EP3035634B1 (de) Telekommunikationsanordnung und verfahren zum herstellen einer rtc-verbindung zwischen einem ersten endpunkt und einem zweiten endpunkt
DE102009043291A1 (de) Automatische Erfassung und Rekonfiguration des Prioritätsstatus in Telekommunikationsnetzen
DE102007060522A1 (de) Aufrechterhaltung der Kommunikation zwischen Netzknoten die eine Paketattacke erfahren
DE60305184T2 (de) Verfahren, mittel und computerprogrammprodukt zur regelung und/ oder einschränkung der benutzung einer telekommunikationsverbindung
WO2005004432A1 (de) Verfahren zur steuerung von datenverbindungen
DE112004001819B4 (de) Endpunkt-Registrierung mit lokaler Verzögerungszeit in einem Rufabwicklungssystem
DE102005039192A1 (de) Verfahren zur Störungsanalyse eines Datenstroms, insbesondere eines Echtzeit-Datenstroms, in einem Datennetz, Kommunikationssystem und Überwachungsrechner
DE102004040482B4 (de) Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1388996B1 (de) Verfahren und Anordnung zum Steuern einer Konferenzschaltung in einem paketorientierten Kommunikationsnetz
DE102005020098B4 (de) Verfahren und System zum Zuweisen von Teilnehmeridentifizierungsdaten zu Netzwerkübertragungsereignissen und Computerprogrammprodukt
EP1678936A2 (de) Verfahren zur aufwandsbeschränkung bei der übertragung von unidirektionalen informationsströmen
DE60307374T2 (de) Selbstverwaltender Verzeichnis-Dienst für Sprache über IP Netzwerk
EP1665676B1 (de) Verfahren zur laststeuerung in einem paketdatennetz
EP1341357B1 (de) Verfahren zur Dienstgütesicherung in einem Kommunikationsnetz sowie Anordnung und Einrichtungen zur Realisierung des Verfahrens
EP1309165A1 (de) Verfahren zum Umschalten zwischen einer Sprachübermittlung und einer Faxübermittlung, Vorrichtung und Computerprogrammprodukt
DE112004002774T5 (de) Optimierung der Ressourcennutzung in einem Paketvermittlungsnetz
DE60318209T2 (de) Modemrelaisansammlungsgerät
EP2649751B1 (de) Verfahren und system zur überwachung eines kommunikationssystems
DE102005003016B4 (de) Verfahren und Vorrichtungen zur Datenübertragung
DE102005035733A1 (de) Verfahren zum Datenaustausch zwischen Netzelementen
DE10345017A1 (de) Verfahren und Vorrichtung zur Adressierbarkeit von Personen für Sprachkommunikation hinter beliebigen verbindungsorientierten Anschlussarten
EP1535477B1 (de) Verfahren zum weiterleiten von signalisierungsnachrichten und zugehörige komponenten
EP1257145A1 (de) Verfahren und Vorrichtungen zur Datenübertragung mit zeitlich veränderlicher Datenrate
DE102005046780A1 (de) Vorrichtung und Verfahren zum Weiterleiten von Telefondaten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060410

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20070130

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SOLUTIONS AND NETWORKS GMBH & CO. KG

RIC1 Information provided on ipc code assigned before grant

Ipc: H04M 7/00 20060101ALI20150914BHEP

Ipc: H04L 29/06 20060101AFI20150914BHEP

Ipc: H04M 3/487 20060101ALI20150914BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20151109

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160322