Voice quality data piggybacking on SIP signaling messages

A call session control function (CSCF) receives, from a first user device engaged in a call with a second user device, a first Session Initiation Protocol (SIP) signaling message piggybacked with first data related to a voice quality of an inbound direction of the call at the first user device. The CSCF receives, from a second user device engaged in the call with the first user device, a second SIP signaling message piggybacked with second data related to a voice quality of an inbound direction of the call at the second user device. The CSCF extracts the first data related to the voice quality from the first SIP signaling message, and extracts the second data related to the voice quality from the second SIP signaling message. A charging collection function (CCF) determines a bi-directional voice quality of the call based on the first data and the second data.

BACKGROUND

The Internet Protocol (IP) multimedia subsystem (IMS), defined by the 3rdGeneration Partnership Project (3GPP), is an architectural framework for implementing IP-based telephony and multimedia services. IMS defines a set of specifications that enables the convergence of voice, video, data and mobile technology over an all IP-based network infrastructure. In particular, IMS fills the gap between the two most successful communication paradigms—cellular and Internet technology, by providing Internet services everywhere using cellular technology in a more efficient way. Session Initiation Protocol (SIP) is the main protocol for IMS. SIP is an application layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Exemplary embodiments described herein use existing SIP signaling messages, required for call termination and call modification, to send voice quality data related to a call to the network. The network may process the voice quality data piggybacked, or inserted in, the SIP signaling messages to generate a quality report that describes the voice quality from both ends of the call. By using SIP signaling messages already being sent for purposes of call termination or call modification, exemplary embodiments described herein do not generate any additional SIP signaling traffic.

FIG. 1illustrates an overview of the piggybacking of voice quality data on SIP signaling messages sent from User Equipment (UE) during call termination or mid-call modification. As shown inFIG. 1, UEs100-1and100-2engage in a call110via a network115. UEs100-1and100-2may include any type of electronic device that may engage in a call. UEs100-1and100-2may include, for example, a telephone (land-line or mobile), a personal digital assistant (PDA), or a computer (e.g., tablet, desktop, palmtop, or laptop).

Subsequent to establishing call110, call110may be terminated by UE100-1, UE100-2, or network115. Additionally, subsequent to establishing call110, call110may be modified mid-call by UE100-1or UE100-2. A mid-call modification may include a call transfer, a call hold, a change of media type from voice call to video call, or a codec change, etc.FIG. 1depicts a call termination or mid-call modification120-1initiated by UE100-1, and a call termination or mid-call modification120-2initiated by UE100-2.FIG. 1further depicts a call termination125initiated by network115. In other examples, UE100-1or UE100-2may initiate call termination.

Prior to call termination/mid-call modification120-1or120-2, or call termination125, UE100-1may measure130-1the inbound voice quality of call110at UE100-1to produce accumulative voice quality data135-1associated with call110until the next SIP signaling event occurs (i.e., when SIP signaling is exchanged between the UE100-1and network115for call modification or call termination). Voice quality data may include several different measurements of the voice quality metrics (e.g., delay, packet error rate, etc.) and the start timestamp and stop timestamp of the measuring duration. UE100-1may then piggyback accumulative voice quality data135-1on a next SIP signaling message140-1sent to a Call Session Control Function (CSCF)145in the IMS network within network115. The voice quality data135-1may be inserted as an XML part to the SIP signaling message or carried by new SIP headers in the SIP signaling message. If this is a mid-call modification, UE100-1will start a new measuring period and continue taking accumulative voice quality measurements until the next signaling event occurs (e.g., another call modification or call termination.) As a result, UE100-1may send voice quality data135-1to CSCF145one time or multiple times for call110, depending on the number of mid-call modifications.

Additionally, or alternatively, subsequent to call termination/mid-call modification120-1or120-2, or call termination125, UE100-2may measure130-2the inbound voice quality of call110at UE100-2to produce accumulative voice quality data135-2associated with call110along with the start time and end time of the measuring period. UE100-2may then piggyback voice quality data135-2on a next SIP signaling message140-2sent to CSCF145in the IMS network within network115in a similar manner as described above for UE100-1.

Upon receipt of SIP signaling message140-1, CSCF145, the entity responsible for generating the accounting record for the call for UE100-1, may extract and store the piggybacked voice quality data135-1from the received SIP signaling message from UE101-1before sending the SIP signaling message to the next node. CSCF145may include voice quality data135-1in the next accounting record150-1that it generates for the call. CSCF145may send the generated accounting record150-1to a Charging Collection Function (CCF)155. CSCF145may send accounting to CCF155via a Charging Data Function (CDF) (not shown inFIG. 1). Accounting record150-1may include voice quality data135-1and regular accounting data for charging. Furthermore, upon receipt of SIP signaling message140-2, CSCF145, as the entity responsible for generating the accounting record for the call for UE100-2, may extract the piggybacked voice quality data135-2and may generate an accounting record150-2. CSCF145may send the generated accounting record150-2to Charging Collection Function (CCF)155. Accounting record150-2may include voice quality data135-2and regular accounting data for charging.

Upon receipt of accounting records150-1and150-2(and possibly other accounting records associated with call110), CCF155may, as shown inFIG. 1, analyze160the voice quality data from both of UEs100-1and100-2. CCF155may extract voice quality data135-1from accounting record150-1, and voice quality data135-2from accounting record150-2. CCF155may analyze voice quality data135-1and135-2to determine a bi-directional voice quality of call110using the voice quality data from both ends of call110. CCF155may generate 165 a report with the determined bi-directional voice quality for the entire call110or for different segments of the call. In some implementation, CCF155may send voice quality135-1and135-2to an external entity responsible for analyzing the data and report generation instead of performing these functions itself.FIG. 1shows the same CSCF145for both UE100-1and UE100-2and one CCF155for simplicity. In other examples, different CSCFs145and different CCFs155may support UE100-1and UE100-2. In this case, CCF155may send voice quality data135-1and135-2to a common server external to CCF155.

FIG. 2depicts an exemplary network environment200in which voice quality data for a call may be piggybacked on SIP signaling messages sent from UEs during call termination or mid-call modification. As shown, network environment200may include UEs100-1and100-2(generically and individually referred to herein as “UE100”) connected with network115via wired or wireless links. As further shown, network115may include a Proxy CSCF (P-CSCF)145-P1, a serving CSCF (S-CSCF)145-S1, an Interrogating CSCF (I-CSCF)145-I, a S-CSCF145-S2, a P-CSCF145-P2, a Charging Data Function (CDF)210, Charging Collection Function155, and a voice quality database (DB)220. P-CSCF145-P1, S-CSCF145-S1, I-CSCF145-I, S-CSCF145-S2, and P-CSCF145-P2may be generically and individually referred to herein as “CSCF145”.

Network115may include one or more networks of any type, including an IMS network. Network115may include one or more wired networks, such as, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cable network, a Public Switched Telephone Network (PSTN), an intranet, and/or the Internet. Network115may further include one or more wireless-based networks, such as, for example, a wireless satellite network and/or a wireless public land mobile network (PLMN). The wireless PLMN may include a Code Division Multiple Access (CDMA) 2000 PLMN, a Global System for Mobile Communications (GSM) PLMN, a Long Term Evolution (LTE) PLMN and/or other types of PLMNs. Network115may implement circuit-switched or packet-switched telephony. The packet-switched telephony may include IP based telephony. The IMS network may use SIP for voice and multimedia session control.

P-CSCF145-P1acts as an edge of the IMS network through which UE100-1obtains access. P-CSCF145-P1maintains an awareness of all IMS endpoints (including UE100-1) that are currently registered with the IMS network, and performs various manipulations of SIP signaling messages that are arriving from, or being sent to, the IMS endpoints (e.g., UE100-1) that are registered with S-CSCF145-S1. P-CSCF145-P1maintains a connection with S-CSCF145-S1for UE100-1.

S-CSCF145-S1processes all originating and terminating SIP requests and responses associated with endpoints registered with S-CSCF145-S1(including UE100-1). S-CSCF145-S1routes the SIP signaling towards its destination (e.g., towards UE100-1via P-CSCF145-P1or toward I-CSCF145-I for UE100-2). S-CSCF may route the SIP signaling request to application server (e.g., Telephony Application Server) for further processing.

I-CSCF145-I passes SIP signaling to/from S-CSCF145-S1and S-CSCF145-S2. I-CSCF145-I queries a Home Subscriber Server (HSS) using diameter signaling (not shown) to learn the identity of the S-CSCF assigned to a given UE so that it can properly forward the SIP signaling.

S-CSCF145-S2processes all originating and terminating SIP requests and responses associated with endpoints registered with S-CSCF145-S2(including UE100-2). S-CSCF145-S2routes the SIP signaling towards its destination (e.g., towards UE100-2via P-CSCF145-P2or towards UE100-1via I-CSCF145-I or S-CSCF145-S1.

P-CSCF145-P2acts as an edge of the IMS network through which UE100-2obtains access. P-CSCF145-P2maintains an awareness of all IMS endpoints (including UE100-2) that are currently registered with the IMS network, and performs various manipulations of SIP signaling messages that are arriving from, or being sent to, the IMS endpoints (e.g., UE100-2) that are registered with CSCF145S2. P-CSCF145-P2maintains a connection with S-CSCF145-S2for UE100-2.

Charging Data Function (CDF)210receives accounting information, including voice quality data for voice calls, from, for example, CSCF145's (e.g., P-CSCF145-P1, S-CSCF145-S1, S-CSCF145-S2, or P-CSCF145-P2). Charging Collection Function (CCF)155collects accounting records from CDF210and stores the voice quality information in voice quality DB220. Voice quality DB220may include a data structure (e.g., a database) that stores voice quality information received from CCF155that may be selectively retrieved. P-CSCF145-P1, S-CSCF145-S1, S-CSCF145-S2, or P-CSCF145-P2, CDF210and CCF155may each include functionality implemented in multiple, different network devices, or in a same, single network device. In the case of more than one CCF155receiving accounting records for a same call, each CCF155may send the voice quality data to voice quality DB220that may be external to CCF155. The handling of regular accounting information for charging may be performed in accordance with existing processes.

The configuration of network components of network environment200shown inFIG. 2is for illustrative purposes. Other configurations may be implemented. Therefore, network environment200may include additional, fewer and/or different components that may be configured in a different arrangement than that depicted inFIG. 2. For example, network environment200may also include a Telephony Application Server (TAS) in network115.FIG. 2depicts a single CDF210and a single CCF155for purposes of clarity. For some calls, one CCF155(and CDF210) may receive accounting record (including voice quality data) from the calling UE100-1and another CCF155(and CDF210) may receive accounting record from the called UE100-2. In this case, each CCF155may send the voice quality data of a call to a common voice quality DB220which may be external to the CCF155and a common processing unit may correlate the measured data from both ends and a common report generation unit may generate the bi-directional voice quality report for the call.

FIG. 3is a diagram that depicts exemplary components of UE100. CSCF145, CDF210, CCF155and voice quality DB220may be similarly configured. UE100may include a bus310, a processing unit320, a main memory330, a read only memory (ROM)340, a storage device350, an input device(s)360, an output device(s)370, and a communication interface(s)380. Bus310may include a path that permits communication among the components of UE100.

Processing unit320may include one or more processors or microprocessors, or processing logic, which may interpret and execute instructions. Main memory330may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing unit320. ROM340may include a ROM device or another type of static storage device that may store static information and instructions for use by processing unit320. Storage device350may include a magnetic and/or optical recording medium. Main memory330, ROM340and storage device350may each be referred to herein as a “tangible non-transitory computer-readable medium.” The process/methods set forth herein can be implemented as instructions that are stored in main memory330, ROM340and/or storage device350for execution by processing unit320.

The software instructions may be read into memory330from another computer-readable medium, such as storage device350, or from another device via communication interface380. The software instructions contained in main memory330may cause processor320to perform operations or processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the principles of the invention. Thus, exemplary implementations are not limited to any specific combination of hardware circuitry and software.

Input device360may include one or more mechanisms that permit an operator to input information to UE100, such as, for example, a keypad or a keyboard, a display with a touch sensitive panel, voice recognition and/or biometric mechanisms, etc. Output device370may include one or more mechanisms that output information to the operator, including a display, a speaker, etc. Input device360and output device370may, in some implementations, be implemented as a user interface (UI) that displays UI information and which receives user input via the UI. Communication interface(s)380may include a transceiver that enables UE100to communicate with other devices and/or systems. For example, communication interface(s)380may include wired and/or wireless transceivers for communicating via network115.

Communication interface(s)380may include functionality for measuring the voice quality on inbound calls received at a transceiver of interface(s)380. The measured voice quality may include, for example, measurements of speech signal level, noise level, echo, delay, packet loss, error rate, jitter, or other quality metrics. Measuring the voice quality may include using algorithms such as Perceptual Evaluation of Speech Quality (PESQ), Perceptual Speech Quality Measure (PSQM), Perceptual Analysis/Measurement System (PAMS) or Mean Opinion Score (MOS).

The configuration of components of UE100illustrated inFIG. 3is for illustrative purposes. Other configurations may be implemented. Therefore, UE100may include additional, fewer and/or different components than those depicted inFIG. 3.

FIG. 4illustrates exemplary details of voice quality DB220. As shown, each entry400of DB220may include a UE identifier (ID) field405, a call ID field410, an other UE ID field415, an inbound voice quality metrics field420, and measurement timestamps field425.

UE ID field405includes a unique identifier for a UE100from which the voice quality information stored in a respective entry400originated. Call ID field410includes a unique identifier that identifies a call that is referenced in a respective entry400. Other UE ID field415includes a unique ID that identifies the other UE100at the other end of the call identified in call ID field410with the UE identified in UE ID field405. Inbound voice quality field420includes voice quality metric measurements (e.g., M1for delay, M2for packet error rate, M3for loss packet rate, etc.) related to the call identified in call ID field410received in a piggybacked SIP signaling message from the UE100identified in UE ID field405. Measurement timestamps field425includes the start timestamp and the stop timestamp for the measurement duration of the voice quality metric measurements in field420.

The number and content of the fields of each entry400of voice quality DB220inFIG. 4is for illustrative purposes. Each entry400of voice quality DB220may include additional, fewer and/or different fields than those depicted inFIG. 4.

FIG. 5is a diagram of exemplary functional components of UE100. The functional components shown inFIG. 5may be implemented in hardware and/or software within UE100. In one implementation, the functional components ofFIG. 5may be implemented as instructions stored in memory330that are executed by processing unit320. The functional components of UE100may include a voice quality data accumulator500, a call status unit510, and a SIP message voice quality piggybacking unit520.

Voice quality data accumulator500may process and store voice quality data measured at, and received from, communication interface(s)380. Accumulator500may provide the voice quality data to unit520for piggybacking on SIP messages. As an implementation option, voice quality data accumulator500may measure voice quality data accumulatively for a fixed period of time (e.g., 5 minutes) and send the voice quality data to SIP Message Voice Quality Piggyback Unit520at the end of the fixed measuring period. In this case, SIP Message Voice Quality Piggyback Unit520may aggregate the voice quality data received from voice quality data accumulator500. Another implementation option is for voice quality data accumulator500to collect and accumulate all measurements and only send data to SIP message voice quality piggybacking unit520whenever there is a mid-call modification or termination detected by call status unit510. In this case, the transmission of voice quality data by voice quality data accumulator500to the SIP message voice quality piggybacking unit520may be triggered by call status unit510or requested by SIP message voice quality piggybacking unit520.

Call status unit510may monitor the status of ongoing calls to determine whether each of the calls is terminated, or modified mid-call. Call status unit510may provide an indication of call termination, or mid-call modification, for a call to unit520.

SIP message voice quality piggybacking unit520may, based on indications of call termination, or mid-call modification, for a particular call received from call status unit510, may piggyback the aggregated voice quality data received from accumulator500on a next outgoing SIP message530.

The configuration of functional components of UE100inFIG. 5is for illustrative purposes only. Other configurations may be implemented. UE100may include additional, fewer, different and/or differently arranged components than those depicted inFIG. 5.

FIG. 6is a diagram of exemplary functional components of CCF155. The functional components shown inFIG. 6may be implemented in hardware and/or software within CCF155. For example, in one implementation, the functional components ofFIG. 6may be implemented as instructions stored in memory330that are executed by processing unit320. The functional components of CCF155may include an accounting record unit600, a voice quality unit610, and a call voice quality report generation unit620.

Accounting record unit600may receive accounting records from CSCF145directly or via CDF210and may extract the voice quality data from the accounting records and store the data in appropriate fields of voice quality DB220. Voice quality unit610may retrieve all voice quality data for a specific call from voice quality DB220, and may process the voice quality data to determine a bi-directional voice quality of the call. The voice quality data retrieved by voice quality unit610may include the inbound voice quality of the call from both ends (i.e., UE100-1and UE100-2) of the call. Voice quality unit610may pass the determined bi-directional voice quality of the call to call voice quality report generation unit620. Call voice quality report generation unit620may generate a voice quality report for a specific call based on the bi-directional voice quality of the call determined by voice quality unit610.

The configuration of functional components of CCF155inFIG. 6is for illustrative purposes only. Other configurations may be implemented. CCF155may include additional, fewer, different and/or differently arranged components than those depicted inFIG. 6. For example, voice quality DB220, voice quality unit610, and voice quality report generation unit620may be integrated in different manners, or may be implemented separately and independently of CCF155, whose main function is collecting accounting data for charging. The processing of the normal accounting data by the CSCF145, CDF210, and CCF155occurs in accordance with existing processes. In many implementations, CDF210and CCF155may be integrated together physically.

FIG. 7is a flow diagram illustrating an exemplary process for measuring voice quality on an inbound direction of a call at a UE100, and piggybacking corresponding voice quality data on a next SIP signaling message from UE100to a CSCF. The exemplary process ofFIG. 7may be performed by processing unit320, in conjunction with communication interface380, of UE100. The exemplary process ofFIG. 7is described herein with reference to the messaging diagram ofFIG. 8. The exemplary process ofFIG. 7may be performed by UE100-1or100-2subsequent to the establishment of a voice call between UE100-1or100-2.

The exemplary process may include measuring the voice quality on an inbound direction of a call to generate voice quality data (block700). Subsequent to establishment of a voice call between UE100and another UE (e.g., between UE100-1and UE100-2), communication interface380of UE100may measure the voice quality on the inbound direction of the voice call. Communication interface380may use existing voice quality measuring techniques to measure the voice quality of the call, and to generate the voice quality data. Voice quality data accumulator500may obtain the voice quality data from communication interface380. The messaging diagram ofFIG. 8depicts UE100measuring805the voice quality of an inbound call800.

UE100may determine whether the call is being terminated or modified (block710). The user of UE100may end the call via input device360, or UE100may receive a SIP BYE message from CSCF145indicating a network-initiated call termination or a call release initiated by the remote end of the call. The user of UE100, via use of input device360, may initiate a mid-call modification, UE100may receive a SIP RE-INVITE message from CSCF145indicating a mid-call modification originating from a remote end of the call (e.g., from the other UE engaged in the call). The mid-call modification may include, for example, a call transfer, a call hold, a change of media type from voice call to video call, or a codec change. Call status unit510may determine whether the call is being terminated or modified based on the user input into UE100, or based on the SIP messages received from CSCF145.

If the call isn't being terminated or modified (NO—block710), then the exemplary process may return to block700with another measurement of the voice quality on the inbound direction of the call. If the call is being terminated or modified (YES—block710), then UE100may generate voice quality data and timestamps for the current measuring period (including accumulative metric measurements and their associated timestamps) (block715) and piggyback the voice quality data on a next SIP signaling message to CSCF145(block720). SIP voice quality piggybacking unit520of UE100may, based on an indication of call termination or modification from call status unit510, obtain voice quality data for the call from voice quality data accumulator500and piggyback the voice quality data on a next SIP signaling message530. The next SIP signaling message530may include a SIP BYE message in the case of a call termination initiated by UE100, a SIP 200 OK message in the case of a network-initiated call termination or a remote-end initiated mid-call modification, or a SIP RE-INVITE message in the case of a mid-call modification initiated by UE100. The messaging diagram ofFIG. 8depicts UE100piggybacking810the voice quality data on a next SIP signaling message.

UE100may send the piggybacked SIP signaling message to CSCF145(block730).FIG. 8depicts SIP message815, piggybacked with the voice quality data, being sent from UE100to CSCF145. The exemplary process ofFIG. 7may return to block700with another measurement of the voice quality on an inbound direction of the call if the call has not been terminated (block740). The exemplary process ofFIG. 7may be repeated for each call at UE100.

FIG. 9is a flow diagram illustrating an exemplary process for including voice quality data extracted from a SIP signaling message received from a UE100in a next accounting record sent from CSCF145to CCF155. In one embodiment, the exemplary process ofFIG. 9may be performed by processing unit320of CSCF145. In another embodiment, the exemplary process ofFIG. 9may be performed by a processing unit of a Telephony Application Server (TAS) and the TAS may perform the blocks of the exemplary process ofFIG. 9, instead of CSCF145. The exemplary process ofFIG. 9is described herein with reference to the messaging diagram ofFIG. 8.

The exemplary process may include receiving, from UE100, a SIP signaling message with piggybacked voice quality data for a call (block900).FIG. 8depicts CSCF145receiving a piggybacked SIP signaling message815from UE100. CSCF145may extract the piggybacked voice quality data from the received SIP signaling message before forwarding the SIP signaling message to a next node (block910). As shown inFIG. 8, upon receipt of piggybacked SIP signaling message815, CSCF145may extract820the piggybacked voice quality data from message815.

CSCF145may generate an accounting record, including the extracted voice quality data and associated time stamps for the call (block920). The accounting record may include various data associated with the call between UE100-1and100-2, including the voice quality data and associated time stamps for the call extracted from the piggybacked SIP signaling message and other data that may be required for charging.FIG. 8depicts CSCF145including the extracted voice quality data in the next accounting record825for the call. CSCF145may send the generated accounting record to CCF155(block930).FIG. 8shows CSCF145sending an accounting record830, with the voice quality data, to CCF155. Alternatively, though not shown inFIG. 8, CSCF145may send signaling message815without extracting the voice quality data to a Telephony Application (TAS). In this case, TAS may perform the functions of extracting voice quality data and including the extracted data in the next accounting record to CCF155.

FIG. 10is a flow diagram illustrating an exemplary process for determining bi-directional voice quality of a call using voice quality data from both ends of the call sent via piggybacked SIP signaling messages. The exemplary process ofFIG. 10may be performed by processing unit320of CCF155. The exemplary process ofFIG. 10may be repeated for each accounting record received at CCF155from CSCF145. The exemplary process ofFIG. 10is described herein with reference to the messaging diagram ofFIG. 8.

The exemplary process may include CCF155receiving an accounting record from CSCF145for a call between UEs100-1and100-2(block1000), extracting voice quality data for the call, and other data, from the accounting record (block1010), and storing the extracted voice quality data, and optionally the other data (e.g., time stamps), in voice quality DB220(block1020). Accounting record unit600may receive the accounting record from CSCF145(directly or via CDF210) and may extract the voice quality data for the call from the accounting record. Accounting record unit600may store the voice quality data in appropriate fields of voice quality DB220. For example, accounting record unit600may store the UE identifier of UE100which originated the voice quality data in UE ID field405, and may store the UE identifier of the other UE100engaged in the call in other UE ID field415. Accounting record unit600may further store an identifier associated with the call in call ID field410, and the voice quality measurements extracted from the accounting record in inbound voice quality field420. Accounting record unit600may store the start timestamp and stop timestamp extracted from the accounting record in timestamps field425. The start and stop timestamps may be used to make sure the entire call duration has been accounted for in the voice quality report generation and/or to assign weights to the associated measurements during analysis and processing. The messaging diagram ofFIG. 8depicts CCF155receiving accounting record830from CSCF145, and extracting835the voice quality data from accounting record830.

CCF155may analyze voice quality DB220to identify voice quality data from UEs on both ends of a call (block1030). Voice quality unit610may retrieve and store voice quality data for a specific call from voice quality DB220, including retrieving the inbound voice quality data of the call from both ends of the call. For example, voice quality unit610may index voice quality DB220to locate entries400whose call ID fields415match the call ID of the call. Voice quality unit610may retrieve the voice quality data stored in inbound voice quality field420and field425of each located entry400. Voice quality unit610may retrieve the UE ID field405and use it to identify the transmission direction of the voice quality data.

CCF155may determine bi-directional voice quality of the call using the identified voice quality data from both ends of the call (block1040), and may generate a voice quality report for the entire call (block1050). Voice quality unit610may process the voice quality data for both ends of the call identified in block1030to determine the bi-directional voice quality of the call. Call voice quality report generation unit620of CCF155may generate a voice quality report using the bi-directional voice quality for the call determined in block1040. The messaging diagram ofFIG. 8depicts CCF155determining840the bi-directional voice quality of the call using voice quality data from both ends of the call, and generating845a voice quality report for the entire call.

FIGS. 11-14depict specific messaging examples associated with piggybacking voice quality data on SIP messages from a UE100.FIG. 11depicts the piggybacking of voice quality data in a SIP message as a consequence of a UE-initiated call release.FIG. 12depicts the piggybacking of voice quality data on SIP messages from a UE100as a consequence of a network-initiated call release.FIG. 13depicts the piggybacking of voice quality data on SIP messages from a UE100as a consequence of a UE-initiated mid-call modification.FIG. 14depicts the piggybacking of voice quality data on SIP messages from a UE100as a consequence of a remote end-initiated mid-call modification.

In the messaging example ofFIG. 11, UE100engages in a call1100with another UE (not shown). UE100itself may then initiate a call release1110(e.g., based on the user of UE100terminating the call). UE100measures1120the voice quality of the call, and then piggybacks1130the voice quality data on a SIP BYE message1140. UE100sends SIP BYE message1140to CSCF145to so that the call can be released, and so CSCF145can generate an accounting record (not shown) that includes the voice quality data. CSCF145may send the accounting record to CCF155for bi-directional voice quality determination and report generation, as described previously herein.

In the messaging example ofFIG. 12, UE100engages in a call1200with another UE (not shown). A network-initiated call release1205occurs and, as a result, CSCF145receives a SIP BYE message1210. CSCF145may send a SIP BYE message1215to UE100notifying UE100of the termination of call1200. UE100measures1220the voice quality of call1200, and then piggybacks1225the voice quality data on a SIP 200 OK message1230. UE100sends SIP 200 OK message1230to CSCF145so CSCF145can generate an accounting record (not shown) that includes the voice quality data. CSCF145may send the accounting record to CCF155for bi-directional voice quality determination and report generation, as described previously herein.

In the messaging example ofFIG. 13, UE100engages in a call1300with another UE (not shown). UE100itself may then initiate a mid-call modification1310(e.g., based on the user of UE100initiating a call transfer, a call hold, a change of media type from voice call to video call, or a codec change). UE100measures1320the voice quality of the call, and then piggybacks1330the voice quality data on a SIP RE-INVITE message1340. UE100sends SIP RE-INVITE message1340to CSCF145so CSCF145can generate an accounting record (not shown) that includes the voice quality data. CSCF145may send the accounting record to CCF155for bi-directional voice quality determination and report generation, as described previously herein.

In the messaging example ofFIG. 14, UE100engages in a call1400with another UE (not shown). A remote-end initiated mid-call modification1405occurs and, as a result, CSCF145receives a SIP RE-INVITE message1410. The remote-end initiated mid-call modification1405may occur due to a user at the UE at the other end of call1400modifying the call (i.e., changing media type from audio to video).

CSCF145may send a SIP RE-INVITE message1415to UE100notifying UE100of the mid-call modification of call1400. UE100measures1420the voice quality of call1400, and then piggybacks1425the voice quality data on a SIP 200 OK message1430. UE100sends SIP 200 OK message1430to CSCF145so CSCF145can generate an accounting record (not shown) that includes the voice quality data. CSCF145may send the accounting record to CCF155for bi-directional voice quality determination and report generation, as described previously herein.

The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while series of blocks have been described with respect toFIGS. 7, 9 and 10, the order of the blocks may be varied in other implementations. Moreover, non-dependent blocks may be performed in parallel.