US20040160896A1 - Method and apparatus for adaptive capture of voice over packet (VoP) data - Google Patents

Method and apparatus for adaptive capture of voice over packet (VoP) data Download PDF

Info

Publication number
US20040160896A1
US20040160896A1 US10/366,993 US36699303A US2004160896A1 US 20040160896 A1 US20040160896 A1 US 20040160896A1 US 36699303 A US36699303 A US 36699303A US 2004160896 A1 US2004160896 A1 US 2004160896A1
Authority
US
United States
Prior art keywords
call
packet
vop
measuring
recited
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.)
Abandoned
Application number
US10/366,993
Other languages
English (en)
Inventor
Steve Luna
Brad Doerr
Alistair Scott
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.)
Agilent Technologies Inc
Original Assignee
Agilent Technologies Inc
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 Agilent Technologies Inc filed Critical Agilent Technologies Inc
Priority to US10/366,993 priority Critical patent/US20040160896A1/en
Assigned to AGILENT TECHNOLOGEIS, INC. reassignment AGILENT TECHNOLOGEIS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DOERR, BRAD, LUNA, STEVE, SCOTT, ALLISTAIR KENNETH CLEMENT
Priority to DE102004001656A priority patent/DE102004001656A1/de
Publication of US20040160896A1 publication Critical patent/US20040160896A1/en
Abandoned legal-status Critical Current

Links

Images

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
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2236—Quality of speech transmission monitoring

Definitions

  • circuit based calls are currently of higher quality than packet based.
  • voice quality is of multiple calls in order to assess the sufficiency of the service for its intended application.
  • Prior art measurement solutions of VoP networks suffer from the difficulty in capturing and measuring all calls simultaneously because current high-bandwidth networks are able to transmit more data than measurement network processors are able to analyze.
  • a prior art testing method includes an active test where a “test call” is established on a network link and known data is transmitted. This testing method suffers from the requirement that any problem in the network must be reconstructed before it can be diagnosed. Accordingly, there is a need for a passive test method wherein measurements of an operational network may be made by eavesdropping. In low bandwidth networks, it is possible to capture and analyze all calls. There remains a need, however, for passive measurement of a high-bandwidth VoP network.
  • a method of measuring a voice over packet (VoP) network comprises the steps of capturing and identifying at least one packet on a network as a VoP signaling packet and determining a call of interest based upon information contained in at least one signaling packet. The method continues with the steps of capturing and identifying at least one additional packet as a VoP data packet, and analyzing the VoP data packet only if the VoP data packet corresponds to the call of interest.
  • VoIP voice over packet
  • a method for measuring voice quality on a voice over packet network comprises the steps of accepting a data packet corresponding to a call and comparing a descriptor of the data packet against a trigger condition. If the trigger condition exists for the data packet, the method further comprises the steps of aggregating the data packet into a flow information record, calculating statistics from the aggregated flow information record, and storing the statistics.
  • An apparatus for measuring a Voice over packet network comprises a filter engine that accepts packets on a network and identifies each packet as one type of packet in a group consisting of a VoP signaling packet, a VoP data packet, and other packets.
  • the apparatus further comprises a call signaling analyzer that accepts the signaling packets and creates a call flow record for an active call.
  • a trigger analyzer accepts parameters to define a call of interest to the filter engine and a flow engine accepts VoP data packets from the filter engine.
  • the apparatus further comprises a flow application that analyzes the VoP packets.
  • a method for measuring a voice over packet network comprising the steps of establishing triggers that define characteristics of one or more calls of interest and capturing data packets for the one or more calls of interest. The method continues by aggregating information based upon the data packets, calculating statistics based upon the aggregated information-, and storing the statistics
  • test system permits real-time analysis of high bandwidth voice over packet networks.
  • FIG. 1 is a simplified block diagram of an illustrative network with voice over packet data.
  • FIG. 2 is a block diagram of an embodiment of a measurement system according to the teachings of the present invention.
  • FIG. 3 is a data flow diagram of an embodiment of a method according to the teachings of the present invention.
  • FIG. 4 is a flow chart of an embodiment of a filter engine according to the teachings of the present invention.
  • FIG. 5 is a flow chart of an embodiment of a call signaling analyzer according to the teachings of the present invention.
  • FIG. 6 is a flow chart of an embodiment of call flow record logic according to the teachings of the present invention.
  • FIG. 7 is a flow chart of an embodiment of a flow engine according to the teachings of the present invention.
  • FIG. 8 is a data flow diagram of an alternate embodiment of a system according to the present teachings.
  • a passive test of a high bandwidth VoP network comprises a method wherein only a subset of all VoP calls on a network are analyzed in order to assess the sufficiency of a VoP link.
  • the subset of VoP calls are termed the “calls of interest” and are isolated from all other calls and data transmitted on the network. Examples of calls of interest that are isolated from the other calls on the network include, but are not limited to calls that contain errors or an abnormal disconnect, calls that use a specific coder/decoder, calls that use a specific path, router or media, calls that originate or terminate at a specific endpoint or caller, calls that implement conference calls, and calls using a long distance service.
  • FIG. 1 of the drawings there is shown a simplified block diagram of an illustrative VoP network wherein a first media gateway 1 accepts conversation traffic from one or more telephones 2 , 3 and perhaps one or more electronic devices such as a computer 4 .
  • the first media gateway accepts the conversation traffic and encodes each conversation into a VoP call using one or more signaling and data VoP protocol packets.
  • the encoded packets of all of the calls and data are launched onto a VoP network 5 .
  • the VoP network 5 is a 100 BaseT Ethernet network link.
  • An opposite side of the VoP network 5 has a second media gateway 6 that receives the encoded packets and routes them to their respective destinations.
  • FIG. 2 of the drawings there is shown a block diagram of a hardware system for implementation of the present teachings in which a a network under test 102 may carry VoP calls for analysis by the illustrated system.
  • the calls may be encoded with any number of VoP protocols including without limitation H.323, media gateway control protocol (MGCP), and session initiation protocol (SIP).
  • a workstation 104 which in a preferred embodiment is a Sun Netra-20 running a Solaris operating system and Agilent Technologies NgN software, is populated with a network card 105 , which in a preferred embodiment is an ENP2506 plug-in network card 105 by Radisys, Corp.
  • the ENP2506 includes an IXP1200 processor with six microprocessor engines.
  • the network card 105 passively monitors data traffic carried by the network under test 102 over the test network connection 108 .
  • the workstation 104 communicates with the network card 105 through a conventional PCI bus 107 and communicates with other devices using a management LAN 106 .
  • External communication over the management LAN 106 is for purposes including without limitation receiving requests from external devices and reporting collected and calculated data to external devices.
  • FIG. 3 of the drawings there is shown a data flow diagram of an embodiment of a method according to the present teachings in which network data on the test link 103 is received by a filter engine 201 .
  • the filter engine 201 is a software process running on four of the microprocessor engines that are on the network card 105 .
  • the filter engine 201 accepts 301 and captures a data packet from the active test link 103 .
  • the data packet is either a VoP signaling packet, a VoP data packet, or some other kind of packet.
  • the filter engine 201 determines through a series of comparisons 302 against known protocols if the data packet is a VoP signal packet and if so, what type of signal protocol is used.
  • the filter engine 201 passes 303 the VoP signaling packet and the protocol type information to a call signaling analyzer 202 and begins the filter engine process for the next consecutive packet on the test link 103 . If the packet is not identified as a VoP signaling packet, the filter engine 201 attempts to identify 304 it as a VoP data packet.
  • a VoP data packets follow a real time protocol and are conventionally termed an “RTP packet”.
  • An RTP packet has header information that includes a timestamp from the sending media gateway, a packet sequence number, an IP address and a port number. The IP address and port number uniquely identify the call to which the RTP packet corresponds.
  • the filter engine identifies the packet as an RTP packet, it forwards 305 the packet to the flow engine 203 and begins the filter engine process for the next consecutive packet on the test link 103 . If the packet is neither a VoP signaling packet nor an RTP packet, then the filter engine discards the packet without further processing. The filter engine process then returns to the beginning to accept and process the next consecutive data packet.
  • the call signaling analyzer is the NgN software product available from Agilent Technologies, Inc.
  • Technology contained in the call signaling analyzer 202 is disclosed is European patent application published Oct. 16, 2002 with publication no. 1249986 and European patent application published Apr. 18, 2001 with publication no. 1093312, the teachings of which are hereby incorporated by reference.
  • the filter engine forwards a stream of VoP signaling packets from the call signaling analyzer at 303 . With each VoP packet in the stream, the filter engine 201 also receives a signaling protocol parameter that indicates the specific signaling protocol used in the VoP signaling packet.
  • the call signaling analyzer 202 accepts the VoP signaling packet and signaling protocol parameter at 401 .
  • the call signaling analyzer 202 determines 402 if a call flow record (CFR) already exists for the call represented by the VoP signaling packet. If the call is new and a CFR does not already exist, the call signaling analyzer establishes 403 a new CFR.
  • the call signaling analyzer then extracts 404 information from the VoP signaling packet and populates the CFR with the extracted information. Multiple VoP signaling packets are used to fully populate the CFR. There is one unique CFR per call on the link.
  • the CFR is a data structure that stores information for the call including:
  • Calling Number The phone number that originated the call.
  • Call ID Identifier assigned by the soft switch to the call.
  • Dialed Number The phone number that was called.
  • IP Addresses IP addresses of all elements involved in call (e.g. soft switch, media gateway, etc).
  • Protocols Signalling protocols used in call.
  • Running Time The duration the call has been running if the call is still in progress.
  • RTP Path Info IP address and UDP ports of RTP stream
  • Answered Whether or not the called party answered the call.
  • Bearer Capability Specifies a requested service: packet or circuit mode, data rate, type of information content.
  • Blocked Any message that affects the blocking condition of a circuit or a group of circuits will be indicated. Circuits may be blocked, unblocked or reset at any time, and one or more calls may be released as a result. If a value is blank, it means that no blocking or unblocking messages were included with this call record.
  • CIC CIC of the IAM portion of the call segment.
  • COTRequested This field will list any protocols that issued a request for a continuity test on the circuit before the call was placed.
  • Call Answer Time Window The time at which the call was answered. If the field is blank, then the call was not answered. Display in SMR tab: HH:MM:SS:mmm
  • Call Create Time The time at which the call started.
  • Call Duration The duration (from connection completed to connection released) of the call.
  • Carrier ID Code A three or four digit number, which uniquely identifies the carrier through which the call was routed (SS7 only).
  • Dial Tone Delay Time from off-hook to dial tone received.
  • Display format HH:MM:SS:mmm
  • DPC Destination Point Code found in the IAM portion of the SS7 protocol.
  • GAP The Generic Address Parameter GAP field from the IAM message (SS7 only). If blank, the IAM message was not seen or did not contain a GAP parameter.
  • JIP The six digit Jurisdiction Information Parameter JIP field from the IAM message. (SS7 only). If blank, the IAM message was not seen, or did not contain a JIP parameter.
  • Local PC Point Code of the local switch or device handling the call (SS7 only). If blank, it means that the IAM message was not seen.
  • LRN The 10-digit Local Routing Number field from the IAM message (SS7 only). If blank, the IAM message was not seen or did not contain a LRN parameter because Local Number Portability was not used.
  • Maintenance Messages Displays Maintenance Messages, for example GRS, GRA, and so on.
  • Originating Answer Delay The time it took for the originating call to be answered. HH:MM:SS:mmm
  • Originating Call Processor The name or IP address of the Call Agent, Call Processor, Media Gateway, Proxy Server or Softswitch that handles the call on the originating side. could be blank if only the terminating side of the call was visible to the NgNAS, or if the call went directly from endpoint to endpoint without going through a switch.
  • Originating Endpoint The name or IP address of the Subscriber Gateway, SIP Entity, or H.323 Terminal that originated the call. could be blank if only the terminating side of the call was visible to the NgNAS.
  • Originating Endpoint Type The type of device that originated the call.
  • OPC Originating Point Code found in the IAM of the SS7 protocol.
  • Originating Release Delay The time it took for the originating device to completely release the call and become available for another call.
  • Originating RTPjitter The RTP jitter reported by the originating side of the call. (MGCP only). HH:MM:SS:mmm
  • Originating RTPlatency The RTP latency reported by the originating side of the call (MGCP only). HH:MM:SS:mmm
  • Originating Packets Rx The RTP packets received by the originating side of the call (MGCP only).
  • Originating Packets Tx The RTP packets sent by the originating side of the call (MGCP only).
  • Originating Packets Lost The RTP packets lost as reported by the originating side of the call (MGCP only).
  • Post Dial Delay The time between when the call originator finished dialing and when the switch indicated that the call was in progress. HH:MM:SS:mmm
  • Release Time Not to be confused with Release Time for CFRs. Timestamp of the last call segment (primitive) that ends the call. Failed calls will not display a Release Time.
  • Release Code For Release Code interpretation, refer to SS7/IPDC Cause Values or MGCP Response Detail.
  • Remote PC Point Code: Point code of the remote end of the call. (SS7 only). If blank, it means that the IAM message was not seen.
  • Softswitch Address The IP address or DNS name of the softswitch that sets up the call. This is obtained from the IP source address field of the RCSI message.
  • Start Time Not to be confused with Call Create Time for CFRs. Timestamp of the first call segment (primitive) that starts the call.
  • Term Answer Delay The time it took for the call to be answered ( from the terminating call's perspective).
  • Term Call Processor The name or IP address of the Call Agent, Call Processor, Media Gateway, Proxy Server or Softswitch that handles the call on the terminating side. could be blank if only the originating side of the call was visible to the NgN application, or if the call went directly from endpoint to endpoint without going through a switch.
  • Term Direction Who terminated the call: Subscriber or Network. If blank, the call never connected, or never disconnected.
  • Term Endpoint The name or IP address of the Subscriber Gateway, SIP Entity, or H.323. terminal that originated the call. could be blank if only the originating side of the call was visible to the NgNAS.
  • Term Endpoint Type The type of device that terminated the call.
  • Term RTP jitter The RTP jitter reported by the terminating side of the call (MGCP only). HH:MM:SS:mmm
  • Term RTP latency The RTP latency reported by the terminating side of the call (MGCP only). HH:MM:SS:mmm
  • Term Packets Rx The RTP packets received by the terminating side of the call (MGCP only).
  • Term Packets Tx The RTP packets sent by the terminating side of the call (MGCP only).
  • Term Packets Lost The RTP packets lost as reported by the terminating side of the call (MGCP only).
  • Time To Answer Time between the IAM and ANM messages. Basically, the time it took for the call to be answered. If the call was not answered (no ANM was received) the field will be blank.
  • Trunking Gateway Address The IP address or DNS name of the trunking gateway that carries the call. This is obtained from the IP destination address field of the RCSI message.
  • Term Release Delay The time it took for the terminating device to completely release the call and become ready for another call. HH:MM:SS:mmm
  • the overall function of the call signaling analyzer is to collect and correlate related VOP signaling packets and to extract information from the VoP signaling packets necessary to populate the CFR data structure for purposes of call test administration.
  • the call signaling analyzer announces 405 the CFR to CFR logic 204 . Accordingly, even if the current call was not completely set-up, the system attempts to capture packets for the call because the failure to set-up may be important data in diagnosing a reported problem.
  • the CFRs are held in memory for some pre-determined period of time.
  • the pre-determined period of time is 30-90 days.
  • access to the CFRs permits later retrieval of measurement data relating to a specific call. This can be important when a call is reported as sub-standard.
  • a service provider using a system according to the teachings of the present invention can receive a complaint and retrieve data on the reported call to ease diagnosis and correction of the problem.
  • the CFR logic process 204 accepts 501 the CFR from the call signaling analyzer 202 when the CFR is announced 405 .
  • the CFR logic determines 502 if the announced CFR contains an IP address and port number of the call. If so, the CFR logic passes 503 the IP address and port number to the filter engine 201 . If the CFR does not contain the IP address and port number, the CFR logic process continues with the step of determining 504 if information contained in the CFR matches any one of a number of triggers 205 .
  • the triggers are conditions or boolean combinations of conditions that define a call of interest.
  • a trigger may be defined for any data field captured by the CFR. As a practical matter, it is believed that some of the more useful triggers are a specific phone number, a route that includes a specific media gateway, signaling gateway, gatekeeper and router, a specific codec, a call that contains a disconnect prior to call termination, a call that contains errors, conference calls and calls of either unusually short or unusually long duration.
  • a trigger may also include a boolean combination of any of the data captured in the CFR. Triggers permit adaptive analysis of only certain calls that assists in the isolation of a problem in a specific piece of equipment or in a specific area of call functionality.
  • An alternative type of trigger identifies call patterns of interest.
  • the CFR logic 204 may be configured to identify an event defined by a combination of calls, such as when there is an initiation and termination of a short first call between two phone numbers and then an initiation of a second call between the same two phone numbers a short time thereafter Such a call pattern may be an indication of poor voice quality on the first call. The second call in the pattern, therefore, would be a call of interest.
  • the CFR logic 204 identifies the call pattern as defined by the triggers 205 and signals the call pattern 507 directly to the flow application 206 .
  • the call pattern signaling from the CFR logic 204 to the flow application 206 provides the flow application 206 with information that identifies the FIR 607 relating to the call is a call of interest based upon a call pattern.
  • a trigger that analyzes only those calls that are processed through the codec assists the user of the new equipment in verifying the functionality of it upon installation.
  • the trigger in this case would be all calls having a specific payload type.
  • a customer may have reported frequent problems in service for conference calls only. Triggering on only conference calls to or from a specific phone number permits analysis of just the reported problem to verify that the problem actually exists and then identifies the magnitude of the problem. Additionally, a user may modify the triggers to methodically isolate a call problem.
  • the triggers are stored in a trigger data file comprising string data separated by semi-colons.
  • the CFR Logic 204 reads the trigger data file.
  • the data trigger file includes an identification of the trigger category, an equals sign, and then the trigger itself.
  • Boolean combinations use the ‘and’ and ‘or’ terminology as well as mathematical ‘greater than’, ‘less than’ and parentheses conventions for more complicated triggers.
  • a single trigger data file may include the following:
  • dialed_num 4155551921
  • Each line that is separated by a semi-colon is a different trigger. Accordingly, all calls that satisfy any one of the triggers are calls of interest. If a customer complained of voice quality, the first two triggers of calling_num and dialed_num permits analysis of only VoP calls to or from that phone number. The third trigger identifies a particular codec on the network. Analysis of calls from one codec allows monitoring a new piece of equipment to assure that its use does not adversely affect voice quality. It is common to capture all calls with identified errors because the error status indicates a problem and collection and analysis of all calls with errors helps to isolate a source of the errors. A user might see that most errors occur when the call passes through one or more media gateways.
  • the user may then modify the trigger to capture all calls with errors that also include the IP address of the media gateway in question.
  • An example of such a trigger is the fourth trigger in the sample triggers. It is also beneficial to analyze calls of both very short duration and very long duration. Long duration calls are interesting because they contain a lot of data and are prone to errors. Short duration calls are interesting because they can possibly signify a voluntary call termination by the caller or callee as a result of poor voice quality.
  • a user can modify the triggers by accessing and modifying the trigger data file. Alternatively, the user may enter the triggers using a graphical user interface (GUI).
  • GUI graphical user interface
  • the CFR logic 204 passes 505 the IP address and port number of the call to the Flow engine 203 .
  • the IP address and port number is possibly sent twice in the CFR logic process. In the first instance, the IP address and port number of any VoP call is sent to the filter engine 201 . Accordingly, the filter engine 201 captures and forwards to the flow engine 203 all RTP packets. In the second instance, the IP address and the port number of only the VoP calls that match the defined trigger criteria are sent to the flow engine 203 .
  • the flow engine 203 processes only those VoP packets that correspond to the calls of interest.
  • the CFR logic 204 determines if the call of interest is based upon a call of interest trigger or is based upon a call pattern trigger 506 . If the call is based upon a call of interest trigger, no further processing is necessary and the process continues from the beginning. If the call is triggered for capture based upon a call pattern of interest, the CFR logic 204 also sends the call pattern information together with the respective FIR to the flow application 206 . In this way, the flow application can identify the call as being part of a call pattern having poor voice quality.
  • the flow engine 203 accepts 601 RTP packets from the filter engine 201 .
  • the flow engine 203 compares 602 the RTP information to the IP address and port number sent 505 by the CFR logic 204 . If the RTP does not match any of the triggers 205 the flow engine 203 does not further process the RTP packet and returns to the beginning of the process to accept the next consecutive RTP packet. If the RTP packet matches the IP address and port number, the flow engine determines whether a flow information record (FIR) exists for the current call. If the FIR does not exist, the flow engine 203 creates and initializes a new FIR and continues.
  • FIR flow information record
  • the flow engine 203 then extracts 604 a sequence number and timestamp from the RTP.
  • the sequence number and timestamp is then aggregated 605 into the FIR for the current call.
  • the flow engine 203 sends 607 all active FIRs to the flow application.
  • the flow application 206 is software that calculates statistics on the aggregated FIRs sent to it by the flow engine. Calculations include, but are not limited to measurements of packet loss, jitter, silence detection, and predictive mean opinion score. The flow application performs all calculations and stores periodic results in a database on a per-call basis. Calculations made by the flow application 206 are accessed by devices via the management LAN 106 for display to a user or for use by other applications such as Agilent Technologies, Inc. Firehunter product to summarize the data over multiple calls.
  • FIG. 8 of the drawings there is shown a data flow diagram of an alternate embodiment according to the teachings of the present invention.
  • a flow application 206 on only a host side of the processor hardware.
  • a host side flow application 206 as well as a card side flow application 207 .
  • the embodiment of FIG. 8 of the drawings is useful if additional processing power were needed to make calculations on the FIRs or if it were beneficial to off-load processing responsibilities from the host workstation 104 to the processors on the network card 105 .
  • each call of interest has one or more call characteristics that are captured by the data in the CFR.
  • call characteristics that are captured by the data in the CFR.
  • calling phone number, called phone number, call duration, and network route The call pattern analysis categorizes and aggregates calls of interest based upon the call characteristics. Call patterns become apparent as a result of the aggregation. This analysis is performed efficiently in the CFR Logic 204 and results are signaled to the flow application 206 .
  • call combinations may also be captured. As an example, combinations of call conditions between the same two phone numbers or common network routes is a potential indicator of poor voice quality.
  • the captured pattern is one or more short duration calls followed quickly by a longer call between the same two phone numbers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Monitoring And Testing Of Exchanges (AREA)
US10/366,993 2003-02-14 2003-02-14 Method and apparatus for adaptive capture of voice over packet (VoP) data Abandoned US20040160896A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/366,993 US20040160896A1 (en) 2003-02-14 2003-02-14 Method and apparatus for adaptive capture of voice over packet (VoP) data
DE102004001656A DE102004001656A1 (de) 2003-02-14 2004-01-12 Verfahren und Vorrichtung für eine adaptive Erfassung von Voice-Over-Paket-Daten (VOP-Daten)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/366,993 US20040160896A1 (en) 2003-02-14 2003-02-14 Method and apparatus for adaptive capture of voice over packet (VoP) data

Publications (1)

Publication Number Publication Date
US20040160896A1 true US20040160896A1 (en) 2004-08-19

Family

ID=32824694

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/366,993 Abandoned US20040160896A1 (en) 2003-02-14 2003-02-14 Method and apparatus for adaptive capture of voice over packet (VoP) data

Country Status (2)

Country Link
US (1) US20040160896A1 (de)
DE (1) DE102004001656A1 (de)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070047694A1 (en) * 2005-08-08 2007-03-01 Jean Bouchard Method, system and apparatus for communicating data associated with a user of a voice communication device
US20070047693A1 (en) * 2005-08-08 2007-03-01 Jean Bouchard Method, system and apparatus for controlling a voice recorder
US7231210B1 (en) * 2004-12-29 2007-06-12 At&T Corp. Method and apparatus for automatically generating call flow test scripts
US20080095144A1 (en) * 2006-10-23 2008-04-24 Net2Phone, Inc. Providing service availability despite bandwidth limitations
US7447159B1 (en) * 2004-12-21 2008-11-04 At&T Corp. Method and apparatus for graphically displaying call signaling flows in a network
US20090129560A1 (en) * 2007-11-20 2009-05-21 At&T Delaware Intellectual Property, Inc. Methods, systems, and computer program products for managing traffic congestion in a network through detection of a source of excessive call volume
US7933263B1 (en) * 2003-02-25 2011-04-26 Jds Uniphase Corporation Analysis of VoIP data using incomplete call information
EP2369807A1 (de) * 2010-03-23 2011-09-28 Voipfuture GmbH Störungserkennung und Aufzeichnung von isochronen Medienströmen
US20120040645A1 (en) * 2009-06-17 2012-02-16 Topaltzas Dimitrios M System, Method and Device for Testing Mobile Telephone Call Performance
EP3799406A1 (de) * 2019-09-27 2021-03-31 Mitel Cloud Services, Inc. Verfahren, system und vorrichtung zur sprachqualitätsüberwachung in der cloud
US20220240344A1 (en) * 2004-08-24 2022-07-28 Comcast Cable Communications, Llc Physical Location Management for Voice Over Packet Communication

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5606668A (en) * 1993-12-15 1997-02-25 Checkpoint Software Technologies Ltd. System for securing inbound and outbound data packet flow in a computer network
US5923673A (en) * 1997-02-13 1999-07-13 Sony Corporation IEEE 1394 data/protocol analyzer
US6078647A (en) * 1997-11-21 2000-06-20 Hewlett Packard Company Method and apparatus for detecting a data service provider in a public switched telephone network
US20010039579A1 (en) * 1996-11-06 2001-11-08 Milan V. Trcka Network security and surveillance system
US6604139B1 (en) * 2001-12-14 2003-08-05 Networks Associates Technology, Inc. Voice protocol filtering system and method
US6795918B1 (en) * 2000-03-07 2004-09-21 Steven T. Trolan Service level computer security
US6870817B2 (en) * 2000-12-20 2005-03-22 Nortel Networks Limited Method and apparatus for monitoring calls over a session initiation protocol network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5606668A (en) * 1993-12-15 1997-02-25 Checkpoint Software Technologies Ltd. System for securing inbound and outbound data packet flow in a computer network
US20010039579A1 (en) * 1996-11-06 2001-11-08 Milan V. Trcka Network security and surveillance system
US5923673A (en) * 1997-02-13 1999-07-13 Sony Corporation IEEE 1394 data/protocol analyzer
US6078647A (en) * 1997-11-21 2000-06-20 Hewlett Packard Company Method and apparatus for detecting a data service provider in a public switched telephone network
US6795918B1 (en) * 2000-03-07 2004-09-21 Steven T. Trolan Service level computer security
US6870817B2 (en) * 2000-12-20 2005-03-22 Nortel Networks Limited Method and apparatus for monitoring calls over a session initiation protocol network
US6604139B1 (en) * 2001-12-14 2003-08-05 Networks Associates Technology, Inc. Voice protocol filtering system and method

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7933263B1 (en) * 2003-02-25 2011-04-26 Jds Uniphase Corporation Analysis of VoIP data using incomplete call information
US11956852B2 (en) * 2004-08-24 2024-04-09 Comcast Cable Communications, Llc Physical location management for voice over packet communication
US20220240344A1 (en) * 2004-08-24 2022-07-28 Comcast Cable Communications, Llc Physical Location Management for Voice Over Packet Communication
US7447159B1 (en) * 2004-12-21 2008-11-04 At&T Corp. Method and apparatus for graphically displaying call signaling flows in a network
US7995486B2 (en) 2004-12-21 2011-08-09 At&T Intellectual Property Ii, L.P. Method and apparatus for graphically displaying call signaling flows in a network
US7231210B1 (en) * 2004-12-29 2007-06-12 At&T Corp. Method and apparatus for automatically generating call flow test scripts
US20070232237A1 (en) * 2004-12-29 2007-10-04 Marian Croak Method and apparatus for automatically generating call flow test scripts
US10116790B2 (en) 2005-08-08 2018-10-30 Bce Inc. Method, system and apparatus for communicating data associated with a user of a voice communication device
US7965821B2 (en) 2005-08-08 2011-06-21 Bce Inc. Method, system and apparatus for controlling a voice recorder
US20070047694A1 (en) * 2005-08-08 2007-03-01 Jean Bouchard Method, system and apparatus for communicating data associated with a user of a voice communication device
US20070047693A1 (en) * 2005-08-08 2007-03-01 Jean Bouchard Method, system and apparatus for controlling a voice recorder
US20080095144A1 (en) * 2006-10-23 2008-04-24 Net2Phone, Inc. Providing service availability despite bandwidth limitations
US20090129560A1 (en) * 2007-11-20 2009-05-21 At&T Delaware Intellectual Property, Inc. Methods, systems, and computer program products for managing traffic congestion in a network through detection of a source of excessive call volume
US8135116B2 (en) * 2007-11-20 2012-03-13 At&T Intellectual Property I, L.P. Methods, systems, and computer program products for managing traffic congestion in a network through detection of a source of excessive call volume
US20120040645A1 (en) * 2009-06-17 2012-02-16 Topaltzas Dimitrios M System, Method and Device for Testing Mobile Telephone Call Performance
US9288695B2 (en) * 2009-06-17 2016-03-15 Spirent Communications, Inc. System, method and device for testing mobile telephone call performance
EP2369807A1 (de) * 2010-03-23 2011-09-28 Voipfuture GmbH Störungserkennung und Aufzeichnung von isochronen Medienströmen
WO2011116938A1 (en) * 2010-03-23 2011-09-29 Voipfuture Gmbh Impairment detection and recording of isochronous media streams
EP3799406A1 (de) * 2019-09-27 2021-03-31 Mitel Cloud Services, Inc. Verfahren, system und vorrichtung zur sprachqualitätsüberwachung in der cloud
US11196870B2 (en) 2019-09-27 2021-12-07 Mitel Clouds Services, Inc. Method, system, and device for cloud voice quality monitoring

Also Published As

Publication number Publication date
DE102004001656A1 (de) 2004-09-02

Similar Documents

Publication Publication Date Title
US7245609B2 (en) Apparatus and method for voice over IP traffic separation and factor determination
US6721284B1 (en) Generating service detail records
US7570743B2 (en) Method and apparatus for surveillance of voice over internet protocol communications
US7729267B2 (en) Method and apparatus for analyzing a media path in a packet switched network
EP1672836A1 (de) Erzeugung von Telefondienstdetailaufzeichnungen mit Dienstgütedaten
US7719965B2 (en) Methods and systems for coordinated monitoring of network transmission events
US8885494B2 (en) System and method for monitoring communications in a network
US7940684B2 (en) Voice over internet protocol (VoIP) testing
US8983046B2 (en) Method and apparatus for providing end-to-end call completion status
US7675948B2 (en) Performance analysis of a circuit switched mobile telecommunications network
US20110235543A1 (en) Dynamically troubleshooting voice quality
US7050549B2 (en) Real time call trace capable of use with multiple elements
US20040160896A1 (en) Method and apparatus for adaptive capture of voice over packet (VoP) data
US20160135030A1 (en) System and method for monitoring communications in a network
US20080112549A1 (en) Method and system for processing billing of including qos information
WO2007079630A1 (fr) Procédé et système permettant de tester la qualité de services (qos) dans un réseau de la prochaine génération (ngn)
US20090059798A1 (en) Apparatus for and method of monitoring QoS metrics of VoIP voice traffic using SIP/RTP
US7903806B1 (en) Expert call analyzer and next generation telephony network configuration system
US20030214963A1 (en) System and method for correlation and real-time display of mapped PSTN trunk identifiers and gateway control protocol endpoints
CN1826757A (zh) 电信网络中的监视
Cisco Troubleshooting with Call Flows
EP0948163A1 (de) Erzeugung von Telefondienstdetailaufzeichnungen
KR100416211B1 (ko) 게이트키퍼 디렉트 모드에서의 과금 부과 방법
Gustafson et al. Evaluation of statistical distributions for VoIP traffic modelling
KR101174027B1 (ko) 암호화된 ＶｏＩＰ 망에서의 미디어 품질 측정 시스템

Legal Events

Date Code Title Description
AS Assignment

Owner name: AGILENT TECHNOLOGEIS, INC., COLORADO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LUNA, STEVE;DOERR, BRAD;SCOTT, ALLISTAIR KENNETH CLEMENT;REEL/FRAME:014054/0966;SIGNING DATES FROM 20030212 TO 20030214

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION