US20020150221A1 - Generating call detail records - Google Patents

Generating call detail records Download PDF

Info

Publication number
US20020150221A1
US20020150221A1 US09/834,046 US83404601A US2002150221A1 US 20020150221 A1 US20020150221 A1 US 20020150221A1 US 83404601 A US83404601 A US 83404601A US 2002150221 A1 US2002150221 A1 US 2002150221A1
Authority
US
United States
Prior art keywords
call
media
identification information
messages
gateways
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
US09/834,046
Inventor
Douglas Carson
Stuart McDonald
David Archibald
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 US09/834,046 priority Critical patent/US20020150221A1/en
Priority to EP02251880A priority patent/EP1249986B1/en
Priority to DE60209182T priority patent/DE60209182T2/en
Priority to JP2002099024A priority patent/JP3753316B2/en
Assigned to AGILENT TECHNOLOGIES, INC. reassignment AGILENT TECHNOLOGIES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AGILENT TECHNOLOGIES UK LIMITED, CARSON, DOUGLAS JOHN
Priority to US10/222,994 priority patent/US7076040B2/en
Publication of US20020150221A1 publication Critical patent/US20020150221A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1043Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1023Media gateways
    • H04L65/1026Media gateways at the edge
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • H04L65/1036Signalling gateways at the edge
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/2218Call detail recording
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/12Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/125Details of gateway equipment
    • H04M7/1255Details of gateway equipment where the switching fabric and the switching logic are decomposed such as in Media Gateway Control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols

Definitions

  • This invention relates to the generation of call detail records for telephone calls and other telecommunications services which are provided through gateways enabling interworking between networks using different networking technologies.
  • the invention has utility for monitoring communications coupled by a Media Gateway between a circuit-switched network and an internet-protocol (IP) network, under the control of a Media Gateway Controller (MGC) using the Media Gateway Control Protocol (MGCP) or the MEGACO/Megacop protocol.
  • IP internet-protocol
  • MCP Media Gateway Control Protocol
  • MEGACO/Megacop protocol Media Gateway Control Protocol
  • circuit-switched telecommunications networks for example the international public switched telephone network (PSTN) are typically configured so that equipment (such as switches) in the transmission or bearer network, which carries user traffic (voice and data signals), is co-located with equipment (such as signalling points) in the associated signalling network, which carries control signals for co-ordinating the operation of the bearer network.
  • equipment such as switches
  • bearer network which carries user traffic (voice and data signals)
  • equipment such as signalling points
  • Dissimilar telecommunications networks are typically interconnected via a “gateway” which provides the necessary conversions or adaptations between the bearer traffic and signalling protocol in each of the networks.
  • control devices such as Media Gateway Controllers can be physically remote from the adaptation devices, such as Media Gateways.
  • Media Gateway Controllers also referred to as call agents or softswitches
  • SGCP Simple Gateway Control Protocol
  • MGCP Media Gateway Control Protocol
  • Media Gateway Controllers communicate with each other using extensions of current Call Control protocols such as Signalling System No.7 ISDN User Part (SS7 ISUP), Session Initiation Protocol (SIP—IETF RFC 2543), or ITU Recommendation H.323. New protocols may be defined for this interface in the future.
  • SS7 ISUP Signalling System No.7 ISDN User Part
  • SIP Session Initiation Protocol
  • ITU Recommendation H.323 ITU Recommendation H.323. New protocols may be defined for this interface in the future.
  • Protocol monitoring applications such as tracing across a signalling network the protocol messages associated with a call, or building Call Data Records (CDRs) to summarise the key parameters relating to a call, require the ability to correlate across different protocols, which may refer to a single entity in multiple different, inconsistent ways. It is an object of this invention to facilitate such correlation.
  • CDRs Call Data Records
  • a method of generating a call detail record for a telecommunications call established via a media gateway under the control of a media gateway controller comprising the steps of:
  • FIG. 1 shows the topology of an exemplary network incorporating multiple telecommunications media and distributed switches
  • FIG. 2 shows part of the network of FIG. 1 in more detail
  • FIG. 3 shows a possible sequence of MGCP commands and responses used to set up a call across a network such as that of FIG. 1;
  • FIGS. 4 a and 4 b comprise a flowchart describing a procedure according to the invention for assembling a call detail record for the call set up by the command sequence of FIG. 3;
  • FIG. 5 shows an example of a call detail record created by the procedure of FIGS. 4 a and 4 b.
  • FIG. 1 shows the primary features of a network for coupling voice telephony and data signals from customer premises equipment (CPE) via an IP packet-switched network to the PSTN.
  • CPE customer premises equipment
  • the CPE 10 analogue phone, personal computer modem etc.
  • a residential media gateway 12 which provides media and signalling conversion functions for transporting voice/data signals from the CPE via an IP network 14 to a second, trunk media gateway 16 .
  • the IP network 14 may be implemented, for example, using digital subscriber line (DSL), cable or fixed wireless technology.
  • DSL digital subscriber line
  • the trunk media gateway 16 provides media and signalling conversion functions for transmission of the voice/data signals onwards over the PSTN, as indicated at 18 , the operation of which is coordinated by an associated signalling network 20 operating in accordance with the Signalling System no.7 (SS7) protocol.
  • SS7 Signalling System no.7
  • Operation of the media gateways 12 and 16 to set up a call through the IP network 14 is coordinated by an MGC 22 .
  • This MGC communicates with the gateways 12 and 16 by using MGCP messages (over IP-based signalling links indicated by dashed lines) and with other nodes in the signalling network 20 (e.g. other MGC's) by using SS7 messages.
  • FIG. 2 illustrates in more detail the functionality incorporated in the gateways 12 and 16 .
  • the residential media gateway 12 implements endpoints, such as 24 , which may for example be connected to external analogue phone lines such as that for the CPE 10 (FIG. 1).
  • Each endpoint has a respective endpoint identifier, comprising the domain name of its gateway (such as rgw 01 for the residential gateway 12 ) and a local name within the gateway (such as p 1 for the endpoint 24 ).
  • the residential gateway 12 also has links to the IP network 14 and can establish an IP connection between such a link and an endpoint in the gateway, by allocating IP resources within the gateway to that endpoint in order to create an IP session which is associated with the endpoint.
  • the allocated IP resources include an IP address (such as 208.1.2.3) and a Real-time Transport Protocol (RTP) port number.
  • RTP Real-time Transport Protocol
  • the residential gateway 12 shares information with the MGC 22 about the IP resources allocated to an endpoint involved in setting up a call, in a Session Description Protocol (SDP) session description, and the MGC 22 forwards this information to the trunk media gateway 16 .
  • This gateway implements endpoints (such as the endpoint t1 @tgw01, connected to the PSTN) in the same manner as the residential gateway 12 , and can likewise allocate IP resources (such as the IP address 208.1.2.5 and the RTP port 1029 ) in order to establish an IP connection between the IP network 14 and that endpoint.
  • IP resources such as the IP address 208.1.2.5 and the RTP port 1029
  • Information about these IP resources is shared by the trunk gateway 16 with the residential gateway 12 via the MGC 22 .
  • FIG. 3 shows the principal features of command and response messages exchanged in IP packets by the MGC 22 with the gateways 12 and 16 to set up and clear a call through the IP network 14 .
  • the endpoints p1 @rgw01 and t1 @tgw01 in the gateways 12 and 16 respectively are represented by the left- and right-hand vertical lines, and the MGC 22 is represented by the central vertical line.
  • Messages passed in IP packets between these units are represented by horizontal arrows, and time runs down the page.
  • the MGC 22 has previously sent a NotificationRequest (RQNT) command to the residential gateway 12 , instructing it to monitor its endpoints for various specified events, including an off-hook transition of associated CPEs, and to notify the MGC 22 of the occurrence of these events.
  • RQNT NotificationRequest
  • the endpoint p1 @rgw01 detects that the CPE 10 connected to it has gone off-hook, it sends a Notify command to the MGC 22 .
  • This command includes a transactionID or transaction number 1230 assigned by the residential gateway 12 , the identity of the relevant endpoint, and an O parameter hd identifying the observed (off-hook) event.
  • the MGC 22 sends a response ( 200 1230 ) confirming reception of the Notify command (identified by its transactionID), and follows this with a NotificationRequest command with an S parameter dl instructing the endpoint to apply dial tone to the connected phone line.
  • the residential gateway 12 collects digits dialled by the customer and then sends a Notify command to the MGC 22 with an O parameter containing the dialled number.
  • the MGC 22 confirms reception of this command, and reacts by sending back a CreateConnection command for the residential gateway 12 to allocate resources to the endpoint p1 @rgw01 for the required call.
  • This command includes a C parameter giving the call a unique CallID identifier ( 99 ).
  • a resulting response from the gateway 12 confirms creation of the required connection to the endpoint p1 @rgw01 and provides an SDP description of this connection, including the IP address (208.1.2.3) and the RTP port ( 48 ) to be used.
  • the MGC 22 forwards this SDP description to the trunk media gateway 16 in another CreateConnection command (transactionID 4230 ), together with the relevant CallID, and the gateway sends a response with the SDP description of the connection it consequently creates to the endpoint t1 @tgw01 specified in the CreateConnection command.
  • This second SDP description is provided by the MGC 22 to the residential media gateway 12 by means of a ModifyConnection command (transactionID 3232 ), including the CallID to identify the relevant call.
  • the gateway 12 sends a response to this command, and thereafter transfer of media (e.g. voice call data) directly between the endpoints in the two gateways 12 and 16 , via the IP network 14 , can take place.
  • media e.g. voice call data
  • the residential media gateway 12 detects and signals this event to the MGC 22 with a Notify command containing the appropriate O parameter hu.
  • the MGC responds by sending DeleteConnection commands containing the relevant CallID) to both the gateways 12 and 16 , which react by removing the associated connections for the specified endpoints (and thus releasing the related IP resources) and sending back confirmatory response messages (250 and transactionID).
  • CDR Call Detail Record
  • OPC originating point code
  • DPC destination point code
  • CIC circuit-identification code
  • call monitoring, fraud detection, billing verification and other network management functions require the availability of CDRs for calls set up via distributed telecommunications switches.
  • the present invention enables such CDRs to be assembled from the MGCP messages (or messages generated in accordance with other functionally similar protocols such as Megacop/H.248).
  • the MGCP signalling links connecting the media gateways 12 and 16 to the MGC 22 are provided with a passive monitoring device 26 as shown in FIG. 2.
  • a passive monitoring device 26 For this purpose equipment of similar functionality to Agilent acceSS7 monitoring equipment for SS7 links may be used, with interfaces adapted to match the communications technology used for the MGCP IP links.
  • the monitoring device 26 detects all MGCP messages traversing the links between the MGC 22 and the gateways 12 and 16 and generates timestamped copies of them, without affecting the transmission of the MGCP messages themselves. These copies are then transferred, for example via a local area network, to a monitoring control centre 28 , which typically comprises data storage equipment and associated data processing equipment operating under the control of appropriate software program instructions to perform the required analyses of the data collected.
  • FIGS. 4 a and 4 b show a procedure in accordance with this invention for assembling CDRs using the copied MGCP messages.
  • the procedure reads each stored MGCP message copy in turn, as represented at step 30 , and then tests at step 32 whether the message is a command message, such as NotificationRequest or Notify, or a response to such a message. In the case where it is a command, the procedure advances to step 34 and tests whether the command message has been sent to or from the MGC 22 .
  • a command message such as NotificationRequest or Notify
  • step 36 For a message sent to the MGC 22 the procedure implements step 36 , to create a temporary association between the source IP address for MGCP IP packets sent by the gateways and the host name in the endpoint specified in the command message (e.g. the host name rgw01); for a message sent from the MGC 22 a counterpart step 38 is implemented, to create a temporary association between the destination IP address for the MGCP IP packets and the endpoint's host name.
  • These temporary associations may involve, for example, creating entries in index tables held in the data storage equipment.
  • the associations enable either one of the IP address and the host name to be determined by reference to the other, and permit meaningful names (as distinct from more obscure IP addresses) to be included in displays of call records. They also enable commands and responses to be matched, by correlating source IP address and transaction number for a command with (the same) destination IP address and transaction number for a response.
  • step 40 to test whether a CallID is present in the command message. If a CallID is not present, a further test is made at step 42 to determine whether the message signals the start of a call (i.e. a Notify command with an O parameter hd). If the message does signify the start of a call, a new call record is created at step 44 (e.g. a new entry is created in a call record table held in the data storage equipment, together with entries in associated index tables). Then at step 46 the endpoint identified in the command message is associated with the new call record (e.g. by entering that endpoint name in an appropriate field in the call record). Thereafter the procedure continues to a step 64 described below.
  • step 48 a test is made to determine whether there is already a call record associated with the endpoint identified in the command message. If not the procedure implements steps 44 and 46 described above; otherwise the procedure advances to the step 64 described subsequently.
  • test at step 40 establishes that a CallID is present in the command message
  • another test at step 50 is carried out to find whether an existing call record is already associated with that CallID. If there is no such call record another test is made at step 52 , to find whether an existing call record is already associated with the endpoint identified in the command message; if no call record is associated with the endpoint a new call record is created, at step 54 , and the endpoint specified in the message is associated with the new record.
  • the CallID specified in the message is associated with the relevant call record (either as already found to exist at step 52 or as created at step 54 ).
  • step 58 determines whether the message is a DeleteConnection (DLCX) command. If so, a timer for the call is started at step 60 , and if not the timer is cancelled at step 62 —in either case the procedure then continues to step 64 .
  • the timer specifies a waiting period to cater for the possibility that another connection might be established for the call; when the timer expires, indicating that no further connection is being made, the call can be treated as having ended and the temporary association between the call record and the endpoint is terminated.
  • step 64 the procedure advances to step 64 , where the source IP address and the transaction number (transactionID) specified in the command message are associated with the relevant call record which has already been created or identified prior to reaching step 64 .
  • step 66 the message itself is appended to the call record, and thereafter the overall procedure is repeated to examine another stored message copy.
  • step 68 the procedure implements step 68 to select the existing call record associated with the destination IP address and the transaction number contained in the message. Then the procedure continues directly to step 66 described above.
  • FIGS. 3, 4 a and 4 b deal primarily with the case of an outbound call being made by the CPE 10 associated with the endpoint in the residential media gateway 12 .
  • the first message is a CreateConnection (CRCX) command to the trunk media gateway 16 , followed by a CRCX command to the residential media gateway 12 with an S parameter rg, to cause the CPE 10 to ring.
  • CRCX command must include the associated unique CallID, the presence of which will be detected at step 40 causing the procedure to continue to step 50 and ultimately to create a new call record.
  • commands are matched with the associated responses (by reference to the IP addresses of MGCP packets and the transactionID—steps 64 and 68 );
  • commands and responses are associated with the part of a call route involving a specific endpoint (by reference to the endpoint names contained in the command messages—steps 46 , 48 , 52 and 54 ); and
  • a call record such as that shown in FIG. 5 is produced for use by other application programs, for example for monitoring quality of service or for billing purposes.

Abstract

Request and response messages conforming to Media Gateway Control Protocol (MGCP) between media gateways 12 and 16 and a media gateway controller (MGC) 22 are examined to enable them to be correlated. The correlated messages are assembled to produce a call detail record (CDR) describing a voice or data call established over an IP network via the media gateways under the control of the MGC.

Description

    TECHNICAL FIELD
  • This invention relates to the generation of call detail records for telephone calls and other telecommunications services which are provided through gateways enabling interworking between networks using different networking technologies. For example, the invention has utility for monitoring communications coupled by a Media Gateway between a circuit-switched network and an internet-protocol (IP) network, under the control of a Media Gateway Controller (MGC) using the Media Gateway Control Protocol (MGCP) or the MEGACO/Megacop protocol. [0001]
  • BACKGROUND ART
  • Existing circuit-switched telecommunications networks, for example the international public switched telephone network (PSTN), are typically configured so that equipment (such as switches) in the transmission or bearer network, which carries user traffic (voice and data signals), is co-located with equipment (such as signalling points) in the associated signalling network, which carries control signals for co-ordinating the operation of the bearer network. [0002]
  • However, attention is now being directed to the possibility of telecommunications networks comprising distributed telecommunications switches, in which there is a separation of the switching/adaptation functionality from the signalling functionality. Furthermore, consideration is being given to the possibility of connecting dissimilar such networks (i.e. networks relying on different bearer technologies and/or signalling protocols). [0003]
  • Dissimilar telecommunications networks are typically interconnected via a “gateway” which provides the necessary conversions or adaptations between the bearer traffic and signalling protocol in each of the networks. In such an architecture control devices such as Media Gateway Controllers can be physically remote from the adaptation devices, such as Media Gateways. Media Gateway Controllers (also referred to as call agents or softswitches) can communicate with the Media Gateways they control using protocols such as Simple Gateway Control Protocol (SGCP), Media Gateway Control Protocol (MGCP—IETF RFC 2705), and the Megacop/H.248 protocol currently being defined. Media Gateway Controllers communicate with each other using extensions of current Call Control protocols such as Signalling System No.7 ISDN User Part (SS7 ISUP), Session Initiation Protocol (SIP—IETF RFC 2543), or ITU Recommendation H.323. New protocols may be defined for this interface in the future. [0004]
  • Protocol monitoring applications, such as tracing across a signalling network the protocol messages associated with a call, or building Call Data Records (CDRs) to summarise the key parameters relating to a call, require the ability to correlate across different protocols, which may refer to a single entity in multiple different, inconsistent ways. It is an object of this invention to facilitate such correlation. [0005]
  • DISCLOSURE OF INVENTION
  • According to one aspect of this invention there is provided a method of generating a call detail record for a telecommunications call established via a media gateway under the control of a media gateway controller, comprising the steps of: [0006]
  • detecting messages exchanged between media gateways and at least one media gateway controller; [0007]
  • locating identification information within the messages; [0008]
  • associating command messages with corresponding response messages in accordance with a first kind of identification information; [0009]
  • associating command and response messages relating to a specific gateway in accordance with a second kind of identification information; [0010]
  • associating messages relating to different gateways in accordance with a third kind of identification information; and [0011]
  • combining the messages which have been associated with one another to produce a call detail record.[0012]
  • BRIEF DESCRIPTION OF DRAWINGS
  • A method and apparatus in accordance with this invention, for correlating gateway command and response messages, will now be described, by way of example, with reference to the accompanying drawings, in which: [0013]
  • FIG. 1 shows the topology of an exemplary network incorporating multiple telecommunications media and distributed switches; [0014]
  • FIG. 2 shows part of the network of FIG. 1 in more detail; [0015]
  • FIG. 3 shows a possible sequence of MGCP commands and responses used to set up a call across a network such as that of FIG. 1; [0016]
  • FIGS. 4[0017] a and 4 b comprise a flowchart describing a procedure according to the invention for assembling a call detail record for the call set up by the command sequence of FIG. 3; and
  • FIG. 5 shows an example of a call detail record created by the procedure of FIGS. 4[0018] a and 4 b.
  • BEST MODE FOR CARRYING OUT THE INVENTION, & INDUSTRIAL APPLICABILITY
  • FIG. 1 shows the primary features of a network for coupling voice telephony and data signals from customer premises equipment (CPE) via an IP packet-switched network to the PSTN. Referring to FIG. 1, the CPE [0019] 10 (analogue phone, personal computer modem etc.) is coupled to a residential media gateway 12, which provides media and signalling conversion functions for transporting voice/data signals from the CPE via an IP network 14 to a second, trunk media gateway 16. The IP network 14 may be implemented, for example, using digital subscriber line (DSL), cable or fixed wireless technology.
  • The [0020] trunk media gateway 16 provides media and signalling conversion functions for transmission of the voice/data signals onwards over the PSTN, as indicated at 18, the operation of which is coordinated by an associated signalling network 20 operating in accordance with the Signalling System no.7 (SS7) protocol.
  • Operation of the [0021] media gateways 12 and 16 to set up a call through the IP network 14 (for example to allocate IP resources within each gateway and communicate related operational information between the gateways) is coordinated by an MGC 22. This MGC communicates with the gateways 12 and 16 by using MGCP messages (over IP-based signalling links indicated by dashed lines) and with other nodes in the signalling network 20 (e.g. other MGC's) by using SS7 messages.
  • FIG. 2 illustrates in more detail the functionality incorporated in the [0022] gateways 12 and 16. Referring to FIG. 2, the residential media gateway 12 implements endpoints, such as 24, which may for example be connected to external analogue phone lines such as that for the CPE 10 (FIG. 1). Each endpoint has a respective endpoint identifier, comprising the domain name of its gateway (such as rgw01 for the residential gateway 12) and a local name within the gateway (such as p1 for the endpoint 24). The residential gateway 12 also has links to the IP network 14 and can establish an IP connection between such a link and an endpoint in the gateway, by allocating IP resources within the gateway to that endpoint in order to create an IP session which is associated with the endpoint. The allocated IP resources include an IP address (such as 208.1.2.3) and a Real-time Transport Protocol (RTP) port number.
  • The [0023] residential gateway 12 shares information with the MGC 22 about the IP resources allocated to an endpoint involved in setting up a call, in a Session Description Protocol (SDP) session description, and the MGC 22 forwards this information to the trunk media gateway 16. This gateway implements endpoints (such as the endpoint t1 @tgw01, connected to the PSTN) in the same manner as the residential gateway 12, and can likewise allocate IP resources (such as the IP address 208.1.2.5 and the RTP port 1029) in order to establish an IP connection between the IP network 14 and that endpoint. Information about these IP resources is shared by the trunk gateway 16 with the residential gateway 12 via the MGC 22. FIG. 3 shows the principal features of command and response messages exchanged in IP packets by the MGC 22 with the gateways 12 and 16 to set up and clear a call through the IP network 14.
  • Referring to FIG. 3, the endpoints p1 @rgw01 and t1 @tgw01 in the [0024] gateways 12 and 16 respectively are represented by the left- and right-hand vertical lines, and the MGC 22 is represented by the central vertical line. Messages passed in IP packets between these units are represented by horizontal arrows, and time runs down the page.
  • It is assumed that the MGC [0025] 22 has previously sent a NotificationRequest (RQNT) command to the residential gateway 12, instructing it to monitor its endpoints for various specified events, including an off-hook transition of associated CPEs, and to notify the MGC 22 of the occurrence of these events. When the endpoint p1 @rgw01 detects that the CPE 10 connected to it has gone off-hook, it sends a Notify command to the MGC 22. This command includes a transactionID or transaction number 1230 assigned by the residential gateway 12, the identity of the relevant endpoint, and an O parameter hd identifying the observed (off-hook) event.
  • The MGC [0026] 22 sends a response (200 1230) confirming reception of the Notify command (identified by its transactionID), and follows this with a NotificationRequest command with an S parameter dl instructing the endpoint to apply dial tone to the connected phone line. After sending a response to this command the residential gateway 12 collects digits dialled by the customer and then sends a Notify command to the MGC 22 with an O parameter containing the dialled number. The MGC 22 confirms reception of this command, and reacts by sending back a CreateConnection command for the residential gateway 12 to allocate resources to the endpoint p1 @rgw01 for the required call. This command includes a C parameter giving the call a unique CallID identifier (99). A resulting response from the gateway 12 confirms creation of the required connection to the endpoint p1 @rgw01 and provides an SDP description of this connection, including the IP address (208.1.2.3) and the RTP port (48) to be used.
  • The MGC [0027] 22 forwards this SDP description to the trunk media gateway 16 in another CreateConnection command (transactionID 4230), together with the relevant CallID, and the gateway sends a response with the SDP description of the connection it consequently creates to the endpoint t1 @tgw01 specified in the CreateConnection command. This second SDP description is provided by the MGC 22 to the residential media gateway 12 by means of a ModifyConnection command (transactionID 3232), including the CallID to identify the relevant call. The gateway 12 sends a response to this command, and thereafter transfer of media (e.g. voice call data) directly between the endpoints in the two gateways 12 and 16, via the IP network 14, can take place.
  • When the transfer has been completed and the customer hangs up, the [0028] residential media gateway 12 detects and signals this event to the MGC 22 with a Notify command containing the appropriate O parameter hu. The MGC responds by sending DeleteConnection commands containing the relevant CallID) to both the gateways 12 and 16, which react by removing the associated connections for the specified endpoints (and thus releasing the related IP resources) and sending back confirmatory response messages (250 and transactionID).
  • The wide variety of different messages and associated parameters involved in the procedure outlined in FIG. 3 preclude simple correlation of the messages to assemble a Call Detail Record (CDR) for a call which is set up using media gateways in the manner described. For example, there is no counterpart to the combination of originating point code (OPC), destination point code (DPC) and circuit-identification code (CIC) which can be used to associate SS7 signalling messages all relating to the same call uniquely with one another —the unique CallID in the CreateConnection command is not necessarily present in every MGCP message. Nonetheless, call monitoring, fraud detection, billing verification and other network management functions require the availability of CDRs for calls set up via distributed telecommunications switches. The present invention enables such CDRs to be assembled from the MGCP messages (or messages generated in accordance with other functionally similar protocols such as Megacop/H.248). [0029]
  • To this end, the MGCP signalling links connecting the [0030] media gateways 12 and 16 to the MGC 22 are provided with a passive monitoring device 26 as shown in FIG. 2. For this purpose equipment of similar functionality to Agilent acceSS7 monitoring equipment for SS7 links may be used, with interfaces adapted to match the communications technology used for the MGCP IP links. The monitoring device 26 detects all MGCP messages traversing the links between the MGC 22 and the gateways 12 and 16 and generates timestamped copies of them, without affecting the transmission of the MGCP messages themselves. These copies are then transferred, for example via a local area network, to a monitoring control centre 28, which typically comprises data storage equipment and associated data processing equipment operating under the control of appropriate software program instructions to perform the required analyses of the data collected.
  • FIGS. 4[0031] a and 4 b show a procedure in accordance with this invention for assembling CDRs using the copied MGCP messages. Referring to FIGS. 4a and 4 b, the procedure reads each stored MGCP message copy in turn, as represented at step 30, and then tests at step 32 whether the message is a command message, such as NotificationRequest or Notify, or a response to such a message. In the case where it is a command, the procedure advances to step 34 and tests whether the command message has been sent to or from the MGC 22. For a message sent to the MGC 22 the procedure implements step 36, to create a temporary association between the source IP address for MGCP IP packets sent by the gateways and the host name in the endpoint specified in the command message (e.g. the host name rgw01); for a message sent from the MGC 22 a counterpart step 38 is implemented, to create a temporary association between the destination IP address for the MGCP IP packets and the endpoint's host name. These temporary associations may involve, for example, creating entries in index tables held in the data storage equipment. The associations enable either one of the IP address and the host name to be determined by reference to the other, and permit meaningful names (as distinct from more obscure IP addresses) to be included in displays of call records. They also enable commands and responses to be matched, by correlating source IP address and transaction number for a command with (the same) destination IP address and transaction number for a response.
  • After implementing either step [0032] 36 or 38, the procedure continues to step 40, to test whether a CallID is present in the command message. If a CallID is not present, a further test is made at step 42 to determine whether the message signals the start of a call (i.e. a Notify command with an O parameter hd). If the message does signify the start of a call, a new call record is created at step 44 (e.g. a new entry is created in a call record table held in the data storage equipment, together with entries in associated index tables). Then at step 46 the endpoint identified in the command message is associated with the new call record (e.g. by entering that endpoint name in an appropriate field in the call record). Thereafter the procedure continues to a step 64 described below.
  • If the test at [0033] step 42 shows that the command message does not signify the start of a call, the procedure moves to step 48 where a test is made to determine whether there is already a call record associated with the endpoint identified in the command message. If not the procedure implements steps 44 and 46 described above; otherwise the procedure advances to the step 64 described subsequently.
  • If the test at [0034] step 40 establishes that a CallID is present in the command message, another test at step 50 is carried out to find whether an existing call record is already associated with that CallID. If there is no such call record another test is made at step 52, to find whether an existing call record is already associated with the endpoint identified in the command message; if no call record is associated with the endpoint a new call record is created, at step 54, and the endpoint specified in the message is associated with the new record. At step 56 the CallID specified in the message is associated with the relevant call record (either as already found to exist at step 52 or as created at step 54).
  • If the test at [0035] step 50 does locate a call record associated with the CallID), a further test is made at step 58 to determine whether the message is a DeleteConnection (DLCX) command. If so, a timer for the call is started at step 60, and if not the timer is cancelled at step 62—in either case the procedure then continues to step 64. The timer specifies a waiting period to cater for the possibility that another connection might be established for the call; when the timer expires, indicating that no further connection is being made, the call can be treated as having ended and the temporary association between the call record and the endpoint is terminated. This ensures that a subsequent message involving that endpoint (for example for an incoming call to the CPE 10 associated with the endpoint) will be correctly recognized as relating to a new call. Detection of any command other than DLCX with the relevant CallID at step 58 indicates that another connection is being established in the call, in which case the timer is cancelled at step 62 to maintain the association of the current call record with the endpoint.
  • Following [0036] steps 46 and 56, or after affirmative results from the tests at steps 48 and 50, the procedure advances to step 64, where the source IP address and the transaction number (transactionID) specified in the command message are associated with the relevant call record which has already been created or identified prior to reaching step 64.
  • Finally, at [0037] step 66, the message itself is appended to the call record, and thereafter the overall procedure is repeated to examine another stored message copy.
  • In the case where the test at [0038] step 32 determines that the message copy being examined is a response message, the procedure implements step 68 to select the existing call record associated with the destination IP address and the transaction number contained in the message. Then the procedure continues directly to step 66 described above.
  • FIGS. 3, 4[0039] a and 4 b deal primarily with the case of an outbound call being made by the CPE 10 associated with the endpoint in the residential media gateway 12. For an inbound call to the CPE the first message is a CreateConnection (CRCX) command to the trunk media gateway 16, followed by a CRCX command to the residential media gateway 12 with an S parameter rg, to cause the CPE 10 to ring. The CRCX command must include the associated unique CallID, the presence of which will be detected at step 40 causing the procedure to continue to step 50 and ultimately to create a new call record.
  • As a result of applying this procedure to a series of MGCP messages, the following correlations are accomplished: [0040]
  • commands are matched with the associated responses (by reference to the IP addresses of MGCP packets and the transactionID—steps [0041] 64 and 68);
  • commands and responses are associated with the part of a call route involving a specific endpoint (by reference to the endpoint names contained in the command messages—steps [0042] 46, 48, 52 and 54); and
  • different parts of a call's route involving different endpoints are associated with one another (by reference to the CallIDs contained in certain command messages—steps [0043] 50 and 56).
  • Further associating all these correlations together in a call detail record enables all the component messages to be correlated with one another, irrespective of the different identifying information contained in different messages. Thus a call record such as that shown in FIG. 5 is produced for use by other application programs, for example for monitoring quality of service or for billing purposes. [0044]

Claims (9)

1. A method of generating a call detail record for a telecommunications call established via a media gateway under the control of a media gateway controller, comprising the steps of:
detecting messages exchanged between media gateways and at least one media gateway controller;
locating identification information within the messages;
associating command messages with corresponding response messages in accordance with a first kind of identification information;
associating command and response messages relating to a specific gateway in accordance with a second kind of identification information;
associating messages relating to different gateways in accordance with a third kind of identification information; and
combining the messages which have been associated with one another to produce a call detail record.
2. The method of claim 1, wherein the first kind of identification information comprises gateway transaction identification information.
3. The method of claim 2, wherein the first kind of identification information includes message addressing information.
4. The method of claim 3, wherein the message addressing information comprises Internet Protocol addresses.
5. The method of claim 1, wherein the second kind of identification information comprises names of media end points within the gateways.
6. The method of claim 1, wherein the third kind of identification information comprises unique identifiers for identifying calls established via a media gateway.
7. The method of claim 1, wherein message addressing information is associated with names of media end points within the gateways.
8. The method of claim 1, wherein a temporary association is made between a call and a name of a media end point within a gateway, and the temporary association is terminated after a predetermined time has elapsed following termination of a connection set up between two gateways for that call.
9. The method of claim 1, wherein the media gateways and the media gateway controller communicate in accordance with the Media Gateway Control Protocol.
US09/834,046 2001-04-12 2001-04-12 Generating call detail records Abandoned US20020150221A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US09/834,046 US20020150221A1 (en) 2001-04-12 2001-04-12 Generating call detail records
EP02251880A EP1249986B1 (en) 2001-04-12 2002-03-15 Generating call detail records
DE60209182T DE60209182T2 (en) 2001-04-12 2002-03-15 Generation of call detail records
JP2002099024A JP3753316B2 (en) 2001-04-12 2002-04-01 How to generate call detail records
US10/222,994 US7076040B2 (en) 2001-04-12 2002-08-19 Generating call detail records

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/834,046 US20020150221A1 (en) 2001-04-12 2001-04-12 Generating call detail records

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/222,994 Continuation-In-Part US7076040B2 (en) 2001-04-12 2002-08-19 Generating call detail records

Publications (1)

Publication Number Publication Date
US20020150221A1 true US20020150221A1 (en) 2002-10-17

Family

ID=25265952

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/834,046 Abandoned US20020150221A1 (en) 2001-04-12 2001-04-12 Generating call detail records
US10/222,994 Expired - Lifetime US7076040B2 (en) 2001-04-12 2002-08-19 Generating call detail records

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/222,994 Expired - Lifetime US7076040B2 (en) 2001-04-12 2002-08-19 Generating call detail records

Country Status (4)

Country Link
US (2) US20020150221A1 (en)
EP (1) EP1249986B1 (en)
JP (1) JP3753316B2 (en)
DE (1) DE60209182T2 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020191589A1 (en) * 2001-04-27 2002-12-19 Dimitrios Vassiliou Method for synchronizing call signaling and voice circuit setup over a voice over internet protocol network
US20030105850A1 (en) * 2001-05-23 2003-06-05 Yoogin Lean Methods and systems for automatically configuring network monitoring system
US20030214971A1 (en) * 2002-05-20 2003-11-20 Sheldon David Charles System and method for mapping a PSTN trunk to a packet network endpoint
US20040114741A1 (en) * 2002-12-12 2004-06-17 Tekelec Methods and systems for defining and distributing data collection rule sets and for filtering messages using same
US20040120350A1 (en) * 2002-12-20 2004-06-24 Tekelec Automatic message accounting record creation system and method
US20050265341A1 (en) * 1998-12-04 2005-12-01 Tekelec Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
US20060268897A1 (en) * 2003-08-19 2006-11-30 Kezhi Qiao Signaling agent realizing method based on media gateway control protocol
US20070174464A1 (en) * 2001-08-15 2007-07-26 Quan Gan Method of calling pc customer terminal transmitting its number in the media gateway control protocol
US20080212573A1 (en) * 2005-05-31 2008-09-04 Rogier Noldus Enhanced Call Detail Record with Information Provided by User
US20090016324A1 (en) * 2005-12-23 2009-01-15 France Telecom Method and Gateway for Connecting IP Communication Entities via a Residential Gateway
US7743131B2 (en) 2000-06-01 2010-06-22 Tekelec Methods and systems for managing status audit messages in a gateway routing node
US7839889B2 (en) 1998-12-04 2010-11-23 Tekelec Methods and systems for communicating signaling system 7 (SS7) user part messages among SS7 signaling points (SPs) and internet protocol (IP) nodes using signal transfer points (STPs)
JP2015186249A (en) * 2014-03-26 2015-10-22 沖電気工業株式会社 Communication system, session controller, and transfer controller
US9219677B2 (en) 2009-01-16 2015-12-22 Tekelec Global, Inc. Methods, systems, and computer readable media for centralized routing and call instance code management for bearer independent call control (BICC) signaling messages
US10264120B2 (en) * 2016-12-30 2019-04-16 Accenture Global Solutions Limited Automated data collection and analytics

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8380840B2 (en) 2001-12-17 2013-02-19 Verizon Business Global Llc Method for recording events in an IP network
US7945592B2 (en) 2001-03-20 2011-05-17 Verizon Business Global Llc XML based transaction detail records
US7406306B2 (en) * 2001-03-20 2008-07-29 Verizon Business Global Llc Method for billing in a telecommunications network
GB2402845A (en) * 2003-06-14 2004-12-15 Agilent Technologies Inc Service usage records for mobile data communications
CN100359900C (en) * 2003-07-07 2008-01-02 中兴通讯股份有限公司 System and method for implementing transaction identifier assignment of media gateway control protocol
US7467210B1 (en) 2004-04-02 2008-12-16 Cisco Technology, Inc. Method and system for automatically collecting information relating to calls to one or more associated endpoint devices
US20070269036A1 (en) * 2004-12-30 2007-11-22 Michael Bates Cross-protocol universal call identifier
CN100417126C (en) * 2005-01-12 2008-09-03 华为技术有限公司 Method of message distribution between media gateway controller and media gateway in next generation network
EP1701530A1 (en) * 2005-03-07 2006-09-13 Siemens Aktiengesellschaft Method and System for providing a VoIP-service by making use of a MGCP controlled CPE
US7844033B2 (en) * 2005-06-03 2010-11-30 Tekelec Methods, systems, and computer program products for generic call tracing
US20070021096A1 (en) * 2005-07-21 2007-01-25 Tekelec Methods, systems, and computer program products associating communications detail records with a mobile reference and using the mobile reference to retrieve the communications detail records
JP4591368B2 (en) * 2006-02-01 2010-12-01 日本電気株式会社 Network, media gateway apparatus, and internal resource management method used therefor
WO2008019087A2 (en) * 2006-08-03 2008-02-14 Bluenote Networks, Inc. Session application records
CN101166179A (en) * 2006-10-16 2008-04-23 华为技术有限公司 Acquisition method, system and network entity for session description protocol capability information
ES2647037T3 (en) * 2007-10-31 2017-12-18 Comptel Corporation Mediation of packet switched calls
CN101902271B (en) * 2009-05-31 2013-03-06 国际商业机器公司 Skew detection method and device and high-speed optical communication interface
GB2517758B (en) * 2013-08-30 2021-04-07 Metaswitch Networks Ltd Call data correlation
CN113747275B (en) * 2021-08-13 2023-05-26 烽火通信科技股份有限公司 Virtual media gateway identification method and device

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI104667B (en) 1997-07-14 2000-04-14 Nokia Networks Oy Implementation of access service
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
US6724747B1 (en) 1997-12-03 2004-04-20 Telcordia Technologies, Inc., A Corp. Of Delaware Method and system for media connectivity over a packet-based network
US6185288B1 (en) * 1997-12-18 2001-02-06 Nortel Networks Limited Multimedia call signalling system and method
US6385301B1 (en) 1998-03-26 2002-05-07 Bell Atlantic Services Network, Inc. Data preparation for traffic track usage measurement
WO2000008819A1 (en) 1998-08-04 2000-02-17 At & T Corp. A method for performing gate coordination on a per-call basis
US6856676B1 (en) * 1998-10-15 2005-02-15 Alcatel System and method of controlling and managing voice and data services in a telecommunications network
US6614781B1 (en) * 1998-11-20 2003-09-02 Level 3 Communications, Inc. Voice over data telecommunications network architecture
US6639981B1 (en) 1999-04-05 2003-10-28 Tekelec Methods and systems for routing signaling messages associated with ported subscribers in a communications network
CA2313439A1 (en) * 1999-10-04 2001-04-04 Faizel Z. Lakhani Method and apparatus for providing telephone service using tdm switches and data transport networks
US6363065B1 (en) 1999-11-10 2002-03-26 Quintum Technologies, Inc. okApparatus for a voice over IP (voIP) telephony gateway and methods for use therein
US6687360B2 (en) * 1999-12-30 2004-02-03 At&T Corp. Personal IP follow-me service

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8750328B2 (en) 1998-12-04 2014-06-10 Tekelec Global, Inc. Methods and systems for communicating signaling system 7 (SS7) user part messages among SS7 signaling points (SPs) and internet protocol (IP) nodes using signal transfer points (STPs)
US8213410B2 (en) 1998-12-04 2012-07-03 Tekelec, Inc. Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
US7839889B2 (en) 1998-12-04 2010-11-23 Tekelec Methods and systems for communicating signaling system 7 (SS7) user part messages among SS7 signaling points (SPs) and internet protocol (IP) nodes using signal transfer points (STPs)
US20050265341A1 (en) * 1998-12-04 2005-12-01 Tekelec Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
US20050286502A1 (en) * 1998-12-04 2005-12-29 Tekelec Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
US8224928B2 (en) 2000-06-01 2012-07-17 Tekelec, Inc. Methods and systems for distributing operating status information within a converged network
US7743131B2 (en) 2000-06-01 2010-06-22 Tekelec Methods and systems for managing status audit messages in a gateway routing node
US20020191589A1 (en) * 2001-04-27 2002-12-19 Dimitrios Vassiliou Method for synchronizing call signaling and voice circuit setup over a voice over internet protocol network
US20030105850A1 (en) * 2001-05-23 2003-06-05 Yoogin Lean Methods and systems for automatically configuring network monitoring system
US7155512B2 (en) 2001-05-23 2006-12-26 Tekelec Methods and systems for automatically configuring network monitoring system
US7680928B2 (en) 2001-05-23 2010-03-16 Tekelec Methods and systems for automatically configuring network monitoring system
US20070124464A1 (en) * 2001-05-23 2007-05-31 Yoogin Lean Methods and systems for automatically configuring network monitoring system
US20070174464A1 (en) * 2001-08-15 2007-07-26 Quan Gan Method of calling pc customer terminal transmitting its number in the media gateway control protocol
US7324502B2 (en) * 2002-05-20 2008-01-29 Agilent Technologies, Inc. System and method for mapping a PSTN trunk to a packet network endpoint
US20030214971A1 (en) * 2002-05-20 2003-11-20 Sheldon David Charles System and method for mapping a PSTN trunk to a packet network endpoint
US7215748B2 (en) 2002-12-12 2007-05-08 Tekelec Methods and systems for defining and distributing data collection rule sets and for filtering messages using same
US20040114741A1 (en) * 2002-12-12 2004-06-17 Tekelec Methods and systems for defining and distributing data collection rule sets and for filtering messages using same
US6968048B2 (en) 2002-12-20 2005-11-22 Tekelec Automatic message accounting record creation system and method
US20040120350A1 (en) * 2002-12-20 2004-06-24 Tekelec Automatic message accounting record creation system and method
US20060268897A1 (en) * 2003-08-19 2006-11-30 Kezhi Qiao Signaling agent realizing method based on media gateway control protocol
US7756142B2 (en) * 2003-08-19 2010-07-13 Zte Corporation Signaling agent realizing method based on media gateway control protocol
US20080212573A1 (en) * 2005-05-31 2008-09-04 Rogier Noldus Enhanced Call Detail Record with Information Provided by User
US20090016324A1 (en) * 2005-12-23 2009-01-15 France Telecom Method and Gateway for Connecting IP Communication Entities via a Residential Gateway
US8879538B2 (en) * 2005-12-23 2014-11-04 Orange Method and gateway for connecting IP communication entities via a residential gateway
US9219677B2 (en) 2009-01-16 2015-12-22 Tekelec Global, Inc. Methods, systems, and computer readable media for centralized routing and call instance code management for bearer independent call control (BICC) signaling messages
JP2015186249A (en) * 2014-03-26 2015-10-22 沖電気工業株式会社 Communication system, session controller, and transfer controller
US10264120B2 (en) * 2016-12-30 2019-04-16 Accenture Global Solutions Limited Automated data collection and analytics

Also Published As

Publication number Publication date
EP1249986B1 (en) 2006-02-15
US7076040B2 (en) 2006-07-11
EP1249986A2 (en) 2002-10-16
EP1249986A3 (en) 2003-11-19
DE60209182D1 (en) 2006-04-20
JP2003018295A (en) 2003-01-17
JP3753316B2 (en) 2006-03-08
DE60209182T2 (en) 2006-07-20
US20030009557A1 (en) 2003-01-09

Similar Documents

Publication Publication Date Title
US7076040B2 (en) Generating call detail records
US8121113B2 (en) Terminal-to-terminal communication connection control method using IP transfer network
US6754180B1 (en) System, method, and computer program product for support of bearer path services in a distributed control network
US6721284B1 (en) Generating service detail records
US8885494B2 (en) System and method for monitoring communications in a network
EP1672835A2 (en) Discovering network configuration
US10659618B2 (en) System and method for monitoring communications in a network
US7054325B1 (en) Correlation of signalling messages
US7539178B2 (en) Connection of users in hybrid communication networks
US7283624B1 (en) Idle detection for answer supervision
KR100416211B1 (en) Accounting Method In Gatekeeper Direct Mode
Cisco Troubleshooting with Call Flows
US20080069311A1 (en) Recording calls in a telecommunication network
KR100445983B1 (en) Internet telephone system and operating method thereof
CA2340293A1 (en) Terminal-to-terminal communication connection control method using ip transfer network
KR100444826B1 (en) Virtual number service method using AICPS.LiTE
EP1279269B1 (en) Method and system for establishing a communication between a first and a second communication entity
JP2006340260A (en) Call control method of internet telephone
KR20060027644A (en) Video telephony service linking system between bcn and internet telephony network and method thereof

Legal Events

Date Code Title Description
AS Assignment

Owner name: AGILENT TECHNOLOGIES, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AGILENT TECHNOLOGIES UK LIMITED;CARSON, DOUGLAS JOHN;REEL/FRAME:012982/0574;SIGNING DATES FROM 20011009 TO 20011016

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE