AU2002252424A1 - XML based transaction detail records - Google Patents

Description

XML BASED TRANSACTION DETAIL RECORDS

The present invention relates to telecommunications, and is more particularly related to recording transaction data in a telecommunications network. There are many factors driving the move toward converged networks such as deregulation, new sources of competition, substantial growth of the Internet, and the growth and importance of data in customers' enterprise networks. The popularity and convenience of the Internet has resulted in the reinvention of traditional telephony services. rP(Internet Protocol) telephony, which is also referred to as Voice-over-IP (VoIP), involves the conversion of voice information into data packets that are subsequently transmitted over an IP network. IP telephony over the Internet is often offered at minimal, or no cost to the users. Thus, IP telephony has found significant success, particularly in the long distance market. Users also have turned to IP telephony as a matter of convenience. Both voice and data services are often accessible through a single piece of equipment, e.g., the personal computer. Furthermore, traditional DTMF (Dual-Tone Multi-Frequency) phones can enjoy the benefits of VoIP technology through the use of network adapters. The continual integration of voice and data services further fuels this demand for telephony applications.

The primary incentives for customers to adopt a converged solution are cost and the promise of new and expanded capabilities. However, if IP telephony is to be fully accepted in the marketplace, VoIP must be interoperable with the Public Switched Telephone Network (PSTN) and have a comparable Quality of Service (QoS). Therefore, to ensure the highest success rate with the customers, the service providers need to build a network that provides call quality, service reliability, and security that is at minimum, on par with the PSTN. It is essential that Telephony solutions meet customer demands of high-quality, ease of use, superior customer service, and lower cost. Since the public Internet can only provide "best- efforts" service, managed IP networks are required to support VoIP traffic with the call quality, service reliability, and security that users are accustomed to.

One approach that is being considered in providing VoIP with the call quality, service reliability, and security that users are accustomed to, involves the Session Initiation Protocol (SIP). SIP is an application-layer signaling protocol that has been developed to create, modify, and terminate sessions with one or more users. These sessions include Internet telephone calls, multi-media conferences, and multi-media distribution. SIP functionality is typically resident on application servers. Sip servers are configured to provide telephony services, and process call event information. Because vendors have developed their own custom SIP application programs, call events and telephony services are processed by each vendor's application server in a proprietary way. Unfortunately, when a network includes network elements provided by a multiplicity of vendors, it becomes necessary to accommodate a variety of proprietary interfaces that enable the devices to transmit and receive network transaction data. By way of example, transaction data may include call event information, billing information, monitoring information, error data, fraud prevention data, timeout data and any other data that must be tracked by the network.

What is needed is a platform independent method for capturing transaction data in a uniform manner. Preferably, the system and method will be extensible, providing embedded information that will enable a receiying computer to read the generic, uniformly formatted records without needing to accommodate any proprietary interface.

The present invention relates to a platform independent method for capturing transaction data and other information in a uniform manner. The method and system of the present invention is extensible, producing generic, uniformly formatted records that can be read by a receiving computer without needing a special proprietary interface.

One aspect of the present invention is a method for recording transactions in a telecommunications network. The method includes creating an XML transaction detail file. At least one transaction detail record is stored in the XML transaction detail file in response to a telecommunications transaction. The at least one transaction detail record includes transaction data corresponding to the telecommunications transaction.

In another aspect, the present invention includes a computer-readable medium having stored thereon a data structure for recording transactions in a telecommunications network. The data structure includes: an XML declaration field, the XML declaration field defining the data structure as an XML file; a server identification field, the server identification field including an IP address of a server generating the XML file; and a transaction detail section including at least one transaction detail record, the at least one transaction detail record being stored in the data structure in response to a telecommunications transaction, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction. In another aspect, the present invention includes a telecommunications network. The network includes at least one telecommunications apparatus configured to perform a telecommunications transaction. At least one SIP-server is coupled to the at least one telecommunications apparatus. The at least one SIP-server is configured to create an XML transaction detail file, process the telecommunications transaction, and store at least one transaction detail record in the XML transaction detail file. The at least one transaction detail record includes transaction data corresponding to the telecommunications transaction.

In another aspect, the present invention includes a computer-readable medium having stored thereon computer-executable instructions for performing a method for recording transactions in a telecommunications network. The method includes creating an XML transaction detail file. The XML transaction detail file is active for a predetermined period of time. At least one transaction detail record is stored in the XML transaction detail file in response to a telecommunications transaction. The at least one transaction detail record includes transaction data corresponding to the telecommunications transaction. Additional features and advantages of the invention will be set forth in the detailed description which follows, and in part will be readily apparent to those skilled in the art from that description or recognized by practicing the invention as described herein, including the detailed description which follows, the claims, as well as the appended drawings.

It is to be understood that both the foregoing general description and the following detailed description are merely exemplary of the invention, and are intended to provide an overview or framework for understanding the nature and character of the invention as it is claimed. The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The drawings illustrate various embodiments of the invention, and together with the description serve to explain the principles and operation of the invention.

Figure 1 is a block diagram of an IP telecommunications network in accordance with one embodiment of the present invention; and

Figure 2 is a chart showing a method for managing telecommunications transactions in accordance with another embodiment of the present invention. Reference will now be made in detail to the present exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. An exemplary embodiment of the network of the present invention is shown in Figure 1, and is designated generally throughout by reference numeral 10.

In accordance with the invention, the present invention includes a method for recording transactions in a telecommunications network. The method includes creating an XML transaction detail file. At least one transaction detail record is stored in the XML transaction detail file in response to a telecommunications transaction. The at least one transaction detail record includes transaction data corresponding to the telecommunications transaction. The present invention provides a platform independent method for capturing transaction data and other information in a uniform manner. The system and method of the present invention is extensible, providing embedded information in generic, uniformly formatted transaction detail records that can be read by a receiving computer without needing a special proprietary interface.

As embodied herein, and depicted in Figure 1, a block diagram of an IP telecommunications network 10 in accordance with one embodiment of the present invention is disclosed. Telecommunications network 10 includes IP network 100, coupled to the Public Switched Telephone Network (PSTN) 20, Internet 30, a customer PBX 40, SIP phones 50, and SlP-clients 52. IP network 100 includes IP network backbone 120. Backbone 120 is coupled to a number of SIP elements that support voice services, including SIP proxy server 102, redirect server (RS) 104, SIP conferencing server 106, voice mail server 108, Operational Support Systems (OSS) 110, Dedicated Access Line (DAL) gateway 112, network gateway 114, INCP gateway 116, and enterprise gateway 118. Network backbone 120 is also directly coupled to Internet 30, SIP phones 50, and SIP Clients 52. Although the present invention is discussed with respect to the Session Initiation Protocol (SIP) and an Internet Protocol (IP)-based network, those of ordinary skill in the art will recognize that the present invention is equally applicable to other telecommunication networks and protocols. network 100 may be of any suitable type, but there is shown by way of 'example a network having a layered architecture. The layered nature of the architecture provides protocol separation and independence, whereby one protocol can be exchanged or modified without affecting the other higher layer or lower layer protocols. It is advantageous that the development of these protocols can occur concurrently and independently. The foundation of the layered architecture is the Internet Protocol (IP) layer. The IP layer provides a connectionless data delivery service that operates on a "best effort" basis; that is, no guarantees of packet delivery are made. A TCP (Transmission Control Protocol) layer is disposed above the IP layer. The TCP layer provides a connection-oriented protocol that ensures reliable delivery of the IP packets, in part, by performing sequencing functions. This sequencing function reorders any IP packets that arrive out of sequence. In another embodiment, the UDP (User Datagram Protocol) is employed instead of TCP. The User Datagram Protocol provides a connectionless service that utilizes the IP protocol to send a data unit, known as a datagram. Unlike TCP, UDP does not provide sequencing of packets. It relies on the higher layer protocols to sort the arriving packets. UDP is preferable over TCP when the data units are small, which saves processing time because of the minimal reassembly time. One of ordinary skill in the art will recognize that embodiments of the present invention can be practiced using either TCP or UDP, as well as other equivalent protocols.

A telephony application layer is disposed over the TCP layer. In one embodiment, the Session Initiation Protocol (SIP) is employed. SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. SP is also a client-server protocol wherein servers respond to requests generated by clients. A detailed discussion of SP and its call control services are described in IETF RFC 2543 and IETF Internet Draft "SP Call Control Services", June 17, 1999. Those of ordinary skill in the art will recognize that application-layer protocols other than SP ^' may be employed, including the H.323 protocol.

Finally, the Session Description Protocol (SDP) is disposed above SP in the layered architecture. SDP provides information about media streams in the multimedia sessions, permitting the recipients of the session description to participate in the session.

P network backbone 120 may be of any suitable type, but there is shown by way of example a network that includes a nationwide high speed network that operates at 622MB/sec (OC-12). Backbone 104 employs advanced packet switching technology commonly known as the Asynchronous Transfer Mode (ATM). Backbone 120 also utilizes a fiber-optic transmission technology referred to as the Synchronous Optical Network (SONET). The combination of ATM and SONET enables high speed, high capacity voice, data, and video signals to be combined and transmitted on demand. The high speed of backbone 120 is achieved by connecting Internet Protocol through the ATM switching matrix, and ninning this combination on the SONET network.

INCP 116 is an Intelligent Network Control Point that is accessed by RS 104 to obtain dial plan information for existing private network customers. INCP 116 is an additional database that may be. queried by RS 104 to route specific private calls. INCP 116 may also be accessed by SPS 102.

PSTN 160 is, by way of example, a circuit switched network employing Signaling System No. 7 (SS7). Plain-Old-Telephone-Service (POTS) telephone 22 maybe any suitable telephone set currently in use or on the market. Enterprise gateway 118 may be of any suitable type. In the example depicted in

Figure 1, enterprise gateway 118 is coupled to PBX 40. Those of ordinary skill in the art will recognize that enterprise gateway 118 may also couple P network 100 to other enterprise networks, such as LANs and/or WANs. Referring back to Figure 1, PBX 40 includes trunks or lines for PBX phones 42. Enterprise gateway 118 provides the interface between packet switched P network 100 and the signaling employed by PBX 40. For example, enterprise gateway 118 may use Integrated Digital Services Network (ISDN), Circuit Associated Signaling (CAS), or other PBX interfaces (e.g., European Telecommunications Standards Institute (ETSI) PRI, R2) to interface with PBX 40.

DAL gateway 112 is a system configured to support private traffic between P locations and non-P locations. DAL gateway 112 may be optionally employed in network 100.

Network gateway 114 is an SS7 (Signaling System 7)/C7-to-SP Gateway. This provides users with the ability to place calls between locations within P network 100 and locations within PSTN 20. For example, network gateway 114 is configured to provide access to a voice switch (not shown), such as a Class 3 switch for domestic call processing, or a Class 5 switch for long-haul and/or international connections.

SP phones 50, and SP-client devices 52, may be of any suitable type provided that they conform to the standards promulgated in IETF 2543. SP phones 50 have a 10-key dial pad similar to traditional phones. SP URLs, which include PSTN 20 numbers, can be entered using the keypad or retrieved from a speed dial directory. To place a call, digits are entered using the dial pad. The entered digits are collected by the phone. When the "Dial" button is pressed, the call is initiated. SP phones 50 ring similar to traditional phones when receiving an incoming call. SP phones 50 may take the form of standalone devices - e.g., a SP phone may be configured to function and appear like a Plain Old Telephone Service (POTS) telephone set. On the other hand, SP client 52 is a software client that runs, for example, on a personal computer (PC) or laptop. From a signaling perspective, SP-devices 50 and 52 are very similar, if not identical, in some cases.

At this point, the various SP-servers disposed in network 100 will be described in more detail. Each type of server in network 100 has a critical role in recording and managing the various transactions supported by network 100.

Referring back to Figure 1, SP-proxy server (SPS) conforms with SP standards detailed per IETF RFC 2543. SPS 102 functions as both a server and a client for the purpose of making requests on behalf of other clients. SPS 102 may service a request directly or pass it on to another server. SPS 102 may also rewrite a message before forwarding it. SPS 102 is configured to create a transaction detail file in XML format to record transaction data processed by SPS 102. The transaction detail file is populated with transaction detail records(TDR). Each TDR records a transaction such as a SP call-event (INVITE, ACK, BYE, CANCEL, OPTIONS, REGISTER, etc.), or any of the otiher events described above, such as errors, or timeouts. SPS 102 includes an XML processor module that is called by

SPS 102 application software to create the XML transaction detail file. The XML processor module may also be called upon to read XML documents, e.g., to provide access to the content and structure of an XML file. The format of the XML transaction detail file is shown in detail in Table I. Table 1 SIP Service Transaction Detail File Structure-Network Server

Authentication <auth_res>text</auth_res> One per Result Authentication

This is a text field that indicates the results of authentication if it was performed. If authentication was not performed, this field will not be present.

The possible values are as follows:

"Pass-Trusted Entity"

"Pass-Authenticated"

"Pass-Non Trusted User"

"Fail-Entity Disabled"

"Fail-System Failure"

"Challenge-User information not found"

"Challenge-Authentication information mismatch"

"Challenge-No local Pending Challenge or Auth Cache Record"

"Challenge-Expired Pending Challenge"

"Challenge-Expired Auth Cache"

Authentication </auth> Optional field - if - End Delimiter present, one per Tdr

Osed to define the end of the Authentication fields wifhing Record a Tdr Record.

Response <response> Optional field - if present one per Tdr

A response contains the information about any SIP record Response that is either sent or received by the NS. NOTE: Responses received from the RS or AUS are not recorded.

Received-from <received-from>AA.BB.CC.DD : port</received-from> One Received-from

(e.g. 166.23.44.157 : 5060) element per

Response

The IP Address that the Response message was received from if the Response was received at the NS, where AA, BB, CC, DD can be digits 0 through 255 and port can be a number 1024 through 65535.

Voice mail server (VMS) 108 is a SP-server that provides voice mail services. Users of the P network 100 are provided with the capability to integrate voicemail services based upon SP. Calls are routed to the voice mail system 108 by SPS 102 and RS 104 for certain calls, such as those that indicate a Busy or Ring No Answer condition. Calls to voice mail can also occur as a Find-Me/Follow-Me termination option, or as an Unconditional Call Forward option selected by the user. Calls by the user to log in and retrieve messages are routed to VMS 108 as a SP endpoint. A voice mail address can be entered for any destination address in RS 104. For instance, the Call Forwarding Unconditional address or Find-Me address, etc., can be the SP URL of a voice mail account. SP enabled VMS 108 supports all alphanumeric SP URLs, Headers, Request, Methods and Status codes (e.g., per IETF RFC 2543). VMS 108 supports SUBSCRIBE, NOTPY, and Message Waiting Indicator (MWI) messages. VMS 108 may restrict access to the system through a variety of ways. Access may be secured through private access code. The access code may be supplied in the SP INVITE message or through DTMF. VMS 108 may reject messages based on the P address of the originating server. In other words, if the message is coming from a server that is not trusted, then VMS 108 may reject the message. VMS 108 is also configured to create a transaction detail file in XML format to thereby record transaction data corresponding to all network transactions processed by VMS 108. Because the format of the VMS XML transaction detail file is very similar . to the SPS 102 XML transaction detail file, it will not be repeated here.

SP conferencing server (SCS) 106 is a centralized SP-conference server configured to provide audio conferencing capabilities. SCS 106 support G.711

(RTP/AVT 0), as well as other codecs. SCS 106 may specify two modes of operation. Under a Reserved mode, the users are required to reserve a bridge ahead of time. An Instant Conferencing mode refers to the ability to set-up a conference as needed without any need for advance reservation, allowing ad-hoc set-up of conferences as well permitting client based conferences to migrate to a bridge. Conference access is secured through an access code. Participants joining the bridge can send their access code via the SP Invite message. POTS telephone users can enter through DTMF depending on the support for DTMF at the gateway. An audible tone may be played to announce each participant as they join the bridge. The system supports a coordinator /operator initiated conference, wherein the operator dials-out to each of the conference participants and brings them into the conference. The conference operator can enter and announce the name of the participants into the conference. The conference coordinator can notify the participants of the time and date for the call. The operators may be able to put parties On and Off Hold. Music On Hold is supported, whereby the parties on Hold are provided with music.

SCS 106 also permits private conferencing (i.e., sub-conferencing), wherein designated conference callers may confer privately within a conference call and then be returned to the main call. Calls from PSTN 20 may be forwarded to SCS 106 by network gateway 114. From the perspective of SCS 106, a SP originated call is not processed differently than a non-SP call because network gateway 114^'is able to translate the called number to the conference URL. However, SCS 106 is able to validate the caller by prompting for passwords and validating the password entered as DTMF digits. As an alternate to password collection through DTMF, SCS 106 may support authentication using SP. In this scenario, the SP INVITE message carries additional user parameters, such as username/password combination that may be used by SCS 106 to validate the user. Further, conferencing system 106 supports web based provisioning by the users. SCS 106 interfaces with the OSS 110 for provisioning, alarming and reporting. The provisioning and reporting interface of the OSS 110 assists with a number of conferencing functionalities, such as the capability to Setup, Modify and Delete conferences. The administrator or moderator of the conference is able to specify the number of attendees to a conference, as well as specify duration of the conference, date and time-by-time zone, and name of reserved conference.

SCS 106 is configured to create a transaction detail file in XML format to thereby record transaction data corresponding to all the above described transactions processed by conferencing server 106. Because the format of the SCS 106 XML transaction detail file is similar to the SPS 102 XML transaction detail file, it will not 'be repeated.

RS 104 is a SIP redirect server that conforms with SIP standards detailed per IETF RFC 2543. RS 104 accepts SIP messages, maps the address into one or more new addresses, and returns these addresses to the client, which could be SPS 102. RS 104 does not initiate its own SP requests, andRS 104 does not accept calls. RS 104 is essentially, a location server wherein information about possible terminating locations can be obtained. RS 104 also serves as a repository for end user information enabling address validation, feature status, and real-time subscriber feature configuration. RS 104 may also be used to store configuration information.

RS 104 is also configured to create a transaction detail file in XML format to thereby record transaction data corresponding to all SP transactions, timeouts and errors processed by RS 104. The transaction detail file includes transaction detail records used to record network transactions processed by RS 104. RS 104 includes an XML processor module that is called by RS 104 application software module to create the XML transaction detail file. The XML processor module may also be called to read an XML file. Because RS 104 has a different function in the management of network 100, its XML transaction detail file is substantially different than the SPS XML transaction detail file. The format of the RS XML transaction detail file is shown in detail in Table IL

Table II SIP Services Transaction Detail File Structure - Redirect Server

Default Nature of <def_noa>text</def_noa> One per Default Number Address

This field records the nature of address that corresponds to the default address that will be used to redirect the call.

The possible values for this field are the following:

"Private"

"E.164"

"Local"

"IP Address"

Default Number-End </defnum> Optional field - if present, one Delimiter per Feature

Used to define the end of the Default Number List fields within a TDR Record

Call Forwarding Busy <cfb> Optional field-if present, one per Feature

This field is used to record information when the Call Forwarding Busy feature is executed at the RS. If the feature is not executed, this field will not be present.

Call Forwarding Busy <cfb_addr>text</cfb_addr> One per Call Forwarding Busy Address

This field record the forwarding address that will be used to redirect the call.

Call Forwarding Busy <cfb_noa>text</cfb_noa> One per Call Forwarding Busy Nature of Address

This field records the nature of address that corresponds to the forwarding address that is used to redirect the call.

The possible values for this field are the following:

"Private"

"E.164"

"Local"

"IP Address"

Call Forwarding </cfb> Optional field-if present, one per

Busy-End Delimiter Feature

Used to define the end of the Call Forwarding Busy fields within a TDR Record

Referring back to Figure 1 , OSS 110 is also a critical system for managing network 100. OSS 110 supports the establishment, provisioning, data collection, and billing of the services of the system 100. OSS 110 is a distributed computing system that includes customer management, account management, billing, network facilities provisioning, and network data collection functionality. All of the XML transaction detail files generated by the above described servers SPS 102, RS 104, SCS 106, and VMS 108, are transmitted to OSS 110 using the XML transaction detail files described above. The XML transaction detail files are used by OSS 110 for a variety of network functions including, but not limited to, network management, billing, and record keeping. Thus, the present invention provides a platform independent method for capturing transaction data in a uniform manner. The present invention is extensible, providing embedded information that will enable any receiving computer to read the generic, uniformly formatted XML files without needing any proprietary interface. In one embodiment, the OSS computing system is based on technology provided by SUN Microsystems, the databases employed by the computing system are based on technology provided by ORACLE. OSS 110 provides and controls access to customer accounts. Users may utilize a web page to monitor service, login to their account, and manage certain elements permitted by user profiles. The account management system allows network personnel to establish, maintain, or deactivate customer accounts. In one embodiment, customer information is viewed via a web interface. The billing system processes customer event records, the customer pricing plan data, adjustments, taxation and other data in the preparation of customer invoices. The network facilities provisioning system provides the information required by network engineers to ensure that the appropriate hardware and software is in place to provide service. This may involve the creation of a customer profile, and the reconfiguration of SPS 102, RS 104, or other network elements. Network provisioning may also require the placement of hardware plug-in devices used in backbone 120.

A process management/work flow system serves as the core of OSS 110. The software is a Common Object Request Broker Architecture (CORBA) based publish- and-subscribe messaging middleware that provides graphical process automation, data transformation, event management and flexible connectors to transact with interfacing applications. This middleware architecture software fulfills the function of integrating all OSS 110 components and may provide hooks to non-OSS components using designated standard interfaces. As embodied herein, and depicted in Figure 2, a chart showing a method for recording telecommunications transaction data in accordance with the present invention is disclosed. The method described herein is equally applicable to SPS 102, RS 104, . SCS 106, and VMS 108. In step 200, the XML detail file is created. If the file is being created in RS 104, XML detail file will have the form depicted in Table π, otherwise, the XML detail file will be of the form, or similar to the form, shown in Table I. Each XML file is active for a predetermined period of time. Thus, once the XML file is created, the server initializes a timer to track elapsed time. For example, OSS 110 may direct each server to keep each XML detail file active for one day, or one hour, as the case may be. In step 204, if a transaction is detected, the server analyzes the transaction and performs an appropriate action. For example, SPS 102 (See Figure 1) may receive an LNViTE message from SIP-phone 50, requesting a session with a user at POTS telephone 22. In processing the LNVITE message, SPS 102 may perform and coordinate a plurality of transactions required to set up the session between SLP phone 50 and POTS telephone 22. In doing so, SPS 102 creates a transaction detail record (TDR) for each transaction in the call set-up process. In step 210, the TDRs are written into the XML file. On the other hand, if there are no transactions generated in the predetermined time period, no records are written into the file. In this case, only the header information in the XML file is transmitted to OSS 110.

Once the timer has elapsed, the server transmits the XML file to OSS 110. After the XML file is transmitted, a new file is created and the process repeats. If the timer has not elapsed, the server waits for additional transactions to process. In step 216, the server may suspend operations for any number of reasons. For example, if the server requires maintenance and is off-line, it is unnecessary to continue to monitor and record network transactions.

Those of ordinary skill in the art will recognize that the use of XML transaction detail files in accordance with the present invention can be employed for any events occurring within network 10. Calls placed between all or any combinations of SL?- phones, enterprise gateways, network gateways, DAL gateways, INCP gateways, SLP- voicemail servers, and SIP conferencing servers may employ the present invention. Those of ordinary skill in the art will also recognize that the present invention can be employed using any suitable type of transport network. Further, the present invention is applicable to any type of session that may be established including, but not limited to, telephony, video, audio, instant messaging, and etc. It is also contemplated that the present invention may be employed for billing, monitoring, management, or for any of a wide variety of services performed by the network. It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

What is claimed is:

1. A method for recording transactions in a telecommunications network, the method comprising: creating an XML transaction detail file; and storing at least one transaction detail record in the XML transaction detail file in response to a telecommunications transaction, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction.

2. The method of claim 1, wherein the XML transaction detail file is active for a predetermined period of time.

3. The method of claim 2, further comprising: closing the XML transaction detail file when the predetermined period of time expires; creating a second XML transaction detail file, the second XML transaction detail file being active for a second predetermined period of time; and repeating the steps of closing and creating for a number of times as directed by a network management system.

4. The method of claim 1, wherein the XML transaction detail file comprises: an XML declaration field, the XML declaration field defining the data structure as an XML file; a server identification field, the server identification field including an IP address of a server generating the XML file; and a transaction detail section including at least one transaction detail record, the at least one transaction detail record being stored in the data structure in response to a telecommunications transaction, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction.

5. The method of claim 1, wherein the telecommunications transaction is conducted between a telecommunications apparatus and a SIP -server.

6. The method of claim 5, wherein the telecommunications apparatus includes a telephone.

7. The method of claim 5, wherein the telecommunications apparatus includes a SLP- device.

8. The method of claim 7, wherein the SLP-device is a telephone.

9. The method of claim 7, wherein the SIP-device is a computer.

10. The method of claim 5, wherein the telecommunications apparatus includes a gateway.

11. The method of claim 5, wherein the SIP-server is a proxy server.

12. The method of claim 5, wherein the SIP-server is a conferencing server.

13. The method of claim 5, wherein the SIP-server is a voice mail server.

14. The method of claim 5, wherein the telecommunications apparatus is a proxy server and the SIP-server is a redirect server.

15. The method of claim 1, wherein the telecommunications transaction includes a SLP- INVITE message.

16. The method of claim 1 , wherein the telecommunications transaction includes a SEP-ACK message.

17. The method of claim 1, wherein the telecommunications transaction includes a SEP- OPTIONS message.

18. The method of claim 1, wherein the telecommunications transaction includes a SIP- BYE message.

19. The method of claim 1, wherein the telecommumcations transaction includes a SIP- CANCEL message.

20. The method of claim 1 , wherein the telecommunications transaction includes a SIP- REGISTER message.

21. The method of claim 1 , wherein the telecόmmumcations transaction includes a billing transaction.

22. The method of claim 1, wherein the telecommunications transaction includes a monitoring transaction.

23. The method of claim 1 , wherein the telecommunications transaction includes a performance measurement transaction.

24. A computer-readable medium having stored thereon a data structure for recording transactions in a telecommunications network, the data structure comprising: an XML declaration field, the XML declaration field defining the data structure as an XML file; a server identification field, the server identification field including an IP address of a server generating the XML file; and a transaction detail section including at least one transaction detail record, the at least one transaction detail record being stored in the data structure in response to a telecommunications transaction, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction.

25. The data structure of claim 24, further comprising a time/date field for indicating the time and date that the XML file was opened.

26. The data structure of claim 24, wherein the data structure is an XML transaction detail file created by an IP network server.

27. The data structure of claim 26, wherein the XML transaction detail file is active for a predetermined period of time.

28. The data structure of claim 26, wherein the server identification field includes the IP address of a proxy server.

29. The data structure of claim 26, wherein the server identification field includes the IP address of a conferencing server.

30. The data structure of claim 26, wherein the server identification field includes the L? address of a voice mail server.

31. The data structure of claim 26, wherein the at least one transaction detail record includes a plurality of transaction detail records.

32. The data structure of claim 31, wherein the at least one transaction detail recorα includes a correlation identification field for correlating each transaction detail record of the plurality of transaction detail records corresponding to a particular transaction.

33. The data structure of claim 26, wherein each transaction detail record includes a time/date field indicating when the transaction detail record was made.

34. The data structure of claim 26, wherein each transaction detail record includes a request section including information about any SL? request that is either sent or received by the IP network server.

35. The data structure of claim 34, wherein the request section includes a received-from field indicating the IP address of the sender of the SlP-request.

36. The data structure of claim 34, wherein the request section includes a sent-to field indicating the IP address of the addressee of the SIP-request.

37. The data structure of claim 34, wherein the request section includes a message field having all data associated with the request.

38. The data structure of claim 26, wherein each transaction detail record includes an authentication section, the authentication section indicates whether an authentication was performed, why the authentication was performed, and the result of the authentication.

39. The data structure of claim 26, wherein each transaction detail record includes a response section including information about any SL? response that is either sent or received by the IP network server.

40. The data structure of claim 39, wherein the response section includes a received- from field indicating the L? address of the sender of the SIP- response.

41. The data structure of claim 39, wherein the response section includes a sent-to field indicating the L? address of the addressee of the SL?- response.

42. The data structure of claim 39, wherein the response section includes a message field having all data associated with the response.

43. The data structure of claim 26, wherein each transaction detail record includes an event section for recording at least one event, other than messages, that occurred at the

IP network server.

44. The data structure of claim 43, wherein the at least one event includes a timeout event.

45. The data structure of claim 43, wherein the at least one event includes an error event.

46. The data structure of claim 24, wherein the data structure is an XML transaction detail file created by a SIP redirect server.

47. The data structure of claim 46, wherein the XML transaction detail file is active for a predetermined period of time.

48. The data structure of claim 46, wherein the server identification field includes the IP address of a redirect server.

49. The data structure of claim 46, wherein the at least one transaction detail record includes a plurality of transaction detail records.

50. The data structure of claim 49, wherein the at least one transaction detail record includes a correlation identification field for correlating each transaction detail record of the plurality of transaction detail records corresponding to a particular transaction.

51. The data structure of claim 46, wherein each transaction detail record includes a time/date field indicating when the transaction detail record was made.

52. The data structure of claim 46, wherein each transaction detail record includes a request section including information about any SIP request that is received by the SL? redirect server from a SLP network server.

53. The data structure of claim 52, wherein the request section includes a received-from field indicating the IP address of an original sender of the SLP-request.

54. The data structure of claim 52, wherein the request section includes a message field having all data associated with the request.

55. The data structure of claim 46, wherein each transaction detail record includes a response section including information about any SIP response that is received by the SEP redirect server from a SIP network server.

56. The data structure of claim 55, wherein the response section includes a sent-to field indicating the L? address of the addressee of the SIP- response.

57. The data structure of claim 55, wherein the response section includes a message field having all data associated with the response.

58. The data structure of claim 46, wherein each transaction detail record includes a features section that records at least one feature executed by the SL? redirect server during the transaction.

59. The data structure of claim 58, wherein the features section includes at least one recursive routing field.

60. The data structure of claim 58, wherein the features section includes at least one originating call validation field, the at least one originating call validation field including data relating to the validation of a call originator, and data relating to the call originator.

61. The data structure of claim 58, wherein the features section includes a non trusted terminating call field for recording whether a non-trusted call was allowed.

62. The data structure of claim 58, wherein the features section includes at least one terminating call validation field, the at least one terminating call validation field including data relating to the validation of a subscriber being called, and data relating to the subscriber.

63. The data structure of claim 58, wherein the features section includes at least one originating call screening field for recording information when a call screening feature s executed.

64. The data structure of claim 58, wherein the features section includes at least one terminating call screening field for recording information when a terminating call screening feature is executed.

65. The data structure of claim 58, wherein the features section includes at least one call forwarding field for recording information when at least one call forwarding feature is executed.

66. The data structure of claim 58, wherein the features section includes at least one find-me field for recording information when a find-me feature is executed.

67. The data structure of claim 58, wherein the features section includes at least one registered address list field for recording information when a call is redirected to a list of registered addresses.

68. The data structure of claim 58, wherein the features section includes at least one default address field for recording information when the call is redirected to a default address in a subscriber's record.

69. The data structure of claim 46, wherein each transaction detail record includes at least one directory access protocol (DAP) field.

70. A telecommunications network, comprising: at least one telecommunications apparatus configured to perform a telecommunications transaction; and at least one SIP-server coupled to the at least one telecommumcations apparatus, the at least one SIP-server being configured to create an XML transaction detail file, process the telecommunications transaction, and store at least one transaction detail record in the XML transaction detail file, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction.

71. The network of claim 70, wherein the telecommunications apparatus includes a SIP device.

72. The network of claim 71, wherein the SL? device includes a telephone.

73. The network of claim 71 , wherein the SL? device includes a computer.

74. The network of claim 71, wherein the telecommunications apparatus includes a SEP proxy server and the at least one SIP-server includes a SEP redirect server.

75. The network of claim 71 , wherein the telecommunications apparatus includes a PBX.

76. The network of claim 71, wherein the telecommunications apparatus includes an enterprise gateway.

77. The network of claim 71, wherein the telecommunications apparatus includes a network gateway.

78. The network of claim 71, wherein the telecommunications apparatus includes a telephone.

79. The network of claim 71, wherein the at least one S P-server includes a SEP proxy server.

80. The network of claim 71, wherein the at least one SIP-server includes a SEP conferencing server.

81. The network of claim 71, wherein the at least one SEP-server includes a SEP voice mail server.

82. A computer-readable medium having stored thereon computer-executable instructions for performing a method for recording transactions in a telecommunications network, the method comprising: creating an XML transaction detail file, the XML transaction detail file being active for a predetermined period of time; storing at least one transaction detail record in the XML transaction detail file in response to a telecommunications transaction, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction.

83. The method of claim 82, further comprising: closing the XML transaction detail file when the predetermined period of time expires; creating a second XML transaction detail file, the second XML transaction detail file being active for a second predetermined period of time; and repeating the steps of closing and creating for a number of times as directed by a network management system.

84. The method of claim 82, wherein the XML transaction detail file comprises: an XML declaration field, the XML declaration field defining the data structure as an XML file; a server identification field, the server identification field including an EP address of a server generating the XML file; and a transaction detail section including at least one transaction detail record, the at least one transaction detail record being stored in the data structure in response to a telecommunications transaction, the at least one transaction detail record including transaction data corresponding to the telecommunications transaction.

85. The method of claim 82, wherein the telecommunications transaction includes a SIP-INVITE message.

86. The method of claim 82, wherein the telecommunications transaction includes a SEP-ACK message.

87. The method of claim 82, wherein the telecommunications transaction includes a SEP-OPTIONS message.

88. The method of claim 82, wherein the telecommunications transaction includes a SIP-BYE message.

89. The method of claim 82, wherein the telecommunications transaction includes a SIP-CANCEL message.

90. The method of claim 82, wherein the telecommunications transaction includes a SEP-REGISTER message.

91. The method of claim 82, wherein the telecommunications transaction includes a billing transaction.

92. The method of claim 82, wherein the telecommunications transaction includes a monitoring transaction.

93. The method of claim 82, wherein the telecommunications transaction includes a performance measurement transaction.