CN101789910A

CN101789910A - Method and device for implementing session history record in converged message service

Info

Publication number: CN101789910A
Application number: CN200910243666A
Authority: CN
Inventors: 卢美莲; 李凤军; 周星; 张永旺; 曾玉冰; 杨栋
Original assignee: ZTE Corp; Beijing University of Posts and Telecommunications
Current assignee: ZTE Corp; Beijing University of Posts and Telecommunications
Priority date: 2009-12-22
Filing date: 2009-12-22
Publication date: 2010-07-28
Anticipated expiration: 2029-12-22
Also published as: CN101789910B

Abstract

The invention provides a method and a device for implementing session history record in converged message service. The method comprises the following steps: receiving a piece of message through a CPM participating function, detecting a session history record function which has been started by a user, resolving the received message according to the protocol type of the received message and executing the session history record function according to the resolving result. Through the processing logic of the session history record function of the CPM participating function, the method and the device realize message and file transmission and session interaction history record function in a converged message service environment.

Description

Method and device for realizing conversation history record in converged message service

Technical Field

The present invention relates to a Converged IP Messaging (CPM) service technology, and more particularly, to a method and an apparatus for implementing a session history in a Converged message service.

Background

Currently, only an Instant Messaging (IM) service has a session History Function in an existing message service, and a session History Function (Conversation History Function) of the IM service is defined in an instant messaging communication based on SIMPLE (OMA SIMPLE IM) service specification.

The media communication type of the IM service is single, and the IM service mainly carries out message communication of discrete media. The message communication mode of the IM includes three types of paging mode, large message mode and session mode. Wherein,

the paging mode refers to that an IM client side directly sends and receives instant messages through a session initiation protocol message (SIP MESSAGE) request, and is suitable for single short message communication such as short messages or announcements with confirmation information;

the large message mode is to use a Message Session Relay Protocol (MSRP) to send a single IM containing large data volume information, for example, when carrying multimedia content. In order to transfer data using the MSRP protocol, a SIP session needs to be established;

session mode refers to requesting initiation of MSRP channel negotiation via session initiation protocol invite (SIP INVITE), all IMs being transmitted over MSRP channel, session mode is not limited to interactive sessions adapted for textual content, such as one-to-one sessions, chat groups, or conferences hosted by some network, and individual users can join and leave sessions at any time.

In order to implement the session history function in the IM service, the session history function in the IM server needs to be located on both the signaling plane and the media plane, and execute the following processing logic:

(1) every time an SIP MESSAGE or MSRP session is received that needs to be stored, the session history function in the IM server checks if there are enough resources to store the SIP message; if not, then either the MSRP session is not recorded SIP MESSAGE and a system message is sent to the user indicating that there is not enough space to store the history, ending; if enough resources exist, turning to (4);

(2) every time an MSRP SEND stored to the IM user it serves is received (as part of a Large message mode message), the conversation historian checks if there are sufficient resources to store the Large message (Large message), if not, stops recording the Large message and discards the Large message that was originally received, then SENDs a system message to the user to indicate that there is not enough space to store the history, and ends; if enough resources exist, turning to (4);

(3) every time an MSRP SEND message is received (as part of an IM session) stored to the IM users it serves, the conversation history function checks if there are sufficient resources to store the MSRP SEND message; if not, then:

stopping recording the message; if the MSRP SEND message is one fragment in a large message interaction, the session history function should reject this message and other fragments of the large message using the MSRP 413 reply and SEND a system message to the user indicating that there is not enough space to store the history, ending; if SEND is part of the session interaction, the session portion that has been stored is maintained, and the session history function SENDs a BYE request to the IM server hosting the conference to exit the conference and a system message to the user indicating that there is not enough space to store the history, ending.

If the resources are enough, turning to (5);

(4) in the case of the SIP MESSAGE request, the complete message (containing the message header and message body) is stored;

(5) in the case of an MSRP session, all relevant header fields From, To, P-Asserted-Identity, Subject, Date of the historical session setup messages (INVITE and 200OK) are stored.

In the above processing logic, a unique history index (URI format, for example 1234@ mailserver. example. com) needs to be allocated to each stored message; for large message mode, store the full MSRP SEND request (containing all header fields, timestamp when the IM server receives the message and the full message content); for session mode, each full MSRP SEND request (containing all header fields, timestamp when the IM server received the message and the full message content) is stored, along with the associated header field of the SIP BYE request.

Moreover, in the existing conversation history record in the IM service, the history record is stored in an IM user account book in the storage entity of the IM server; and the metadata is stored in the IM XDMS.

Through the processing logic, the IM server realizes the function of recording the conversation history, and completely records the interactive instant messages in the conversation process, no matter in a paging mode, a large message mode or a conversation mode.

The communication media types of the IM services are single, and only discrete media (such as text, pictures, audio/video segments, etc.) using instant messages as carriers are interacted in the session, the types of the related signaling message types and session state information types are also few, so that when the IM server performs the session history recording function, methods of storing a complete SIP MESSAGE message or a complete msrp send message, or storing relevant headers of messages such as SIP INVITE/SIP 200OK, etc. are basically adopted.

In the IM service, the actual content of the conversation history is stored in the IM server, and the metadata related to the conversation history is additionally stored in the IM XML Document Management Server (XDMS), so that the way of storing the metadata separately from the conversation history content itself makes it necessary for the IM client to access the IM XDMS to obtain the corresponding information by using the XCAP protocol when obtaining the conversation history function, and then access the IM server to obtain the actual content of the conversation history according to the information by using the SIP protocol, thereby complicating the management and operation of the conversation history.

As network technology evolves, Messaging services provided over communication networks have shown a Converged trend, and for this purpose, OMA organizations have provided a Converged IP Messaging Enabler (CPM Enabler) that can span different access networks and be built on top of a unified IP core network to support one-to-one, one-to-many, and communication with various media types (e.g., text, pictures, audio/video clips, binary files, audio/video streams) between end users and applications.

In a converged messaging environment, a CPM enabler provides a CPM service to a user by taking a CPM session as a unit to perform information interaction, and the user hopes a network side to record and store historical interaction information of the CPM session participated in by the user in the communication process, so that the aim of truly reproducing the whole process of the session participated in by the user by sending a request to a network side server to access the historical interaction record information of the CPM session participated in by the user when needed is achieved; furthermore, it is also possible to manage the session history information of the user itself stored in the network side server.

Herein, a server providing a CPM user with a function of storing a CPM session history is referred to as a CPM message storage server, and a CPM message storage client accesses and manages the CPM session history and related contents belonging to the CPM user by accessing the CPM message storage server, and presents views and contents of sessions to the CPM user by parsing session history information acquired from a network side.

The CPM session describes the behavior of information interaction between communication parties by using a CPM enabler functional entity, and the CPM session consists of any number of CPM messages interacted outside the session, CPM file transmission and CPM sessions. Wherein, a CPM message is an information body that may contain a plurality of discrete, i.e., non-continuous, media (e.g., text, pictures, audio clips, video clips, etc.); CPM file transmission is a process of transmitting one or more files carrying multimedia content between participants, and a recipient user must explicitly confirm a reception process before receiving any data of the transmitted files; a CPM session is a logical connection between two or more participants for a period of time, and may be used for participants to exchange continuous media in real time, as well as for exchanging discrete media. The CPM message interaction and the CPM file transmission can be performed in a CPM session or outside the CPM session. It is generally recognized that each CPM session contains only one CPM session at a particular time. A user may participate in multiple CPM sessions in parallel.

The CPM session history is a stored representation of the CPM session. The authorized responsible person can acquire and store the information exchanged during the CPM session, and store the information as a CPM session history in a CPM message storage server provided by the CPM service provider. At this time, one CPM message interacted outside the CPM session is stored as one CPM message record, CPM file transmission performed outside the CPM session is stored as one CPM file transmission history, and one CPM session is stored as one CPM session history (including data of CPM message within the session, CPM file transmission within the session, and continuous media segments interacted within the session). Therefore, the CPM session history can be described as a set of a CPM message record, a CPM file transfer history, and a CPM session history in the sense of a storage representation.

In the CPM service, since a converged messaging service is provided, the types of the related communication media are richer, and besides discrete media, IP-based voice stream and video stream communication, i.e., CPM sessions, can be provided. The CPM session can be further divided into a 1-1CPM session and a CPM group session, in the group session, since participants can be removed, invited, actively joined, actively left, and other events of state change of the session occur, interactions involving various SIP signaling such as SIP INVITE, SIP REFER, SIP 200OK, SIP BYE, and these SIP messages represent different semantics in different context environments of the session, if a session history recording function in the existing IM service is further adopted, these interaction information are only stored completely, and it is impossible to truly record the state change information of the whole session.

For example, for the message record, if only the session history function in the IM service is used, and only one piece of SIP MESSAGE or MSRP SEND is completely stored, then the CPM message storage client and the CPM message storage server need to understand details such as formats of the communication protocol messages when parsing the content of the session history, that is, the session history function in the existing IM service is directly applied to the CPM service, which is poor in universality and extensibility.

The session history of IM uses processing logic that starts the recording process each time the IM server receives an instant message, without considering how the session history should be updated (e.g., deleting the message record of the failed transmission or adding the recorded information of the failed transmission) if the message fails to be transmitted (the receiver does not successfully receive). In a word, the conversation history recording function of the IM service is a simpler functional prototype, and does not consider complete processing logic; in the converged messaging service, providing a complete session history for the user is a very important feature as a CPM service, and a session history function is required to have more complete processing logic. For example, in the CPM service, the session history function and related metadata may be stored in a unified manner on the message storage server, and both the message storage client and the CPM participating function access the message storage server through the IMAP4 protocol, so that the processing logic of the session history function of the conventional IM service cannot be directly reused in the CPM service, and based on the essence of the converged message service provided by the CPM service and the specific protocol architecture characteristics thereof, a new processing logic suitable for the characteristics of the session history function of the CPM service needs to be defined.

Disclosure of Invention

In view of the above, the main objective of the present invention is to provide a method and an apparatus for implementing a history record of a conversation in a converged messaging service, so as to implement a history record function of message, file transmission and session interaction in a converged messaging service environment.

In order to achieve the purpose, the technical scheme of the invention is realized as follows:

a method for realizing conversation history record in converged message service comprises the following steps:

the converged IP message CPM participation function receives a message, detects that a user has started a session history function, analyzes the received message according to a protocol type of the received message, and executes the session history function according to an analysis result.

The protocol type of the received message is an SIP protocol message, and the analyzing the received message and executing the conversation history recording function according to the analyzing result comprises the following steps:

calling an SIP protocol stack to analyze the received SIP protocol message, and processing SIP INVITE message when the analyzed result is SIP INVITE; when the analyzed result is SIP BYE, SIP BYE message processing is carried out; when the analyzed result is SIP REFER, SIP REFER message processing is carried out; when the analyzed result is SIP MESSAGE, SIP MESSAGE message processing is performed.

The protocol type of the received message is MSRP protocol message, and the functions of analyzing the received message and executing the conversation history record according to the analysis result comprise:

and calling an MSRP protocol stack to analyze the received MSRP protocol message, and when the message is analyzed to be MSRPSEND, processing the MSRP SEND message.

If the continuous media stream data packet is received and it is detected that the CPM session recording function is turned on, the method further includes:

the CPM participation function records continuous media streams of parties participating in the conversation, starts a media mixing function, mixes the media streams of the parties participating in the CPM conversation and stores the mixed media stream data;

and after the CPM session is ended, the CPM participation function extracts the locally cached mixed media stream data packet, codes the media stream data packet according to the requirement of the storage format of the session history record, and then encapsulates the media stream object code into a CPM session history record object.

The SIP INVITE message processing includes:

when the CPM participation function caches the SIP INVITE message locally, waiting for receiving a response message of success or failure returned by the receiver and caching;

the CPM participation function checks CPM feature tags carried in an Accept-Contact header field and a Contact header field of the SIP INVITE message, and respectively carries out corresponding processing on a temporary SIP session establishment request message which is indicated by the CPM feature tags and is established for transmitting a CPM large message, or a temporary SIP session establishment request message which is established for transmitting a CPM file, or an SIP session establishment request message which is related to a CPM session event.

The processing of the temporary SIP session establishment request message established for CPM large message transmission includes:

when the temporary SIP session establishment request message established for the transmission of the large message in the CPM session is judged, searching the CPM session to which the CPM large message belongs by calculating and comparing the Dialog-ID, finding a session history record object of the corresponding CPM session, and extracting related information from the INVITE message for recording; recording in a CPM session history object according to a response message of success or failure related to the INVITE request; waiting for receiving the MSRP SEND message at a port of a designated MSRP media channel;

when it is determined that the message is the temporary SIP session establishment request message established for large message transmission outside the CPM session, then,

after judging that the SIP temporary session is successfully established according to the response message, the CPM participation function creates a CPM message recording object, and extracts related information from the SIP INVITE request message for recording according to the provision of a CPM message uniform storage format; waiting for receiving the MSRP SEND message at the port of the designated MSRP media channel.

The processing of the temporary SIP session establishment request message established for CPM file transfer includes:

if the message is the request message for establishing the temporary SIP session established for file transmission in the CPM session, searching the CPM session to which the CPM file belongs by calculating and comparing the Dialog-ID, finding a session history record object of the corresponding CPM session, and extracting relevant information from the INVITE message for recording; recording in a CPM session history object according to a response message of success or failure related to the INVITE request; waiting for receiving the MSRP SEND message at a port of a designated MSRP media channel;

when it is judged that the temporary SIP session establishment request message is established for file transfer other than the CPM session and it is judged that the SIP temporary session establishment is successful according to the response message, then,

the CPM participation function creates a CPM file transmission history object, and extracts related information from the SIP INVITE request message for recording according to the provision of the uniform storage format of the CPM file transmission history; waiting for receiving the MSRP SEND message at the port of the designated MSRP media channel.

The processing of the SIP session establishment request message related to the CPM session event includes:

when judging that the SIP session establishment request message related to the CPM session event is a session establishment request message initiated for establishing a new CPM session, the CPM participation function creates a new CPM session history record object in a local storage space; extracting relevant information from the SIP INVITE message and recording the information according to the storage format of the CPM session history record; recording a result of the CPM session creation event according to a response message of success or failure returned to the INVITE message, also as a part of the CPM session history object;

when judging that the SIP session establishment Request message related to the CPM session event is a session joining Request message initiated by a certain CPM user for applying for joining an ongoing CPM session, finding a corresponding CPM session history record object through a CPM session identifier indicated in a Request-URI; extracting relevant information from the SIP INVITE message and recording according to the specification of a session history record storage format; according to a response message of success or failure returned to the INVITE message, the result of the request to join the CPM session event is recorded, also as a part of the CPM session history object.

The method further comprises the following steps: the Request-URI of the Request message is checked SIP INVITE,

if the value of the Request-URI is a CPM session identifier, the SIP INVITE Request message is a session joining Request message initiated by a certain CPM user for applying for joining an ongoing CPM session;

if the value of the Request-URI is the address of the CPM control function and the tag parameter in the To header field is null, the SIP INVITE Request message is a session establishment Request message initiated for an ongoing Ad-hoc group CPM session;

if the value of the Request-URI is the address of the CPM user and the tag parameter in the To header field is null, the SIP INVITE Request message is a session establishment Request message initiated for establishing a new 1-1CPM session;

if the value of the Request-URI is the address of the CPM group and the tag parameter in the To header field is null, the SIP INVITE Request message is a session establishment Request message initiated for establishing a new predefined group CPM session.

The SIP BYE message processing comprises the following steps:

the CPM participation function caches the SIP BYE message locally, waits for receiving and caching a successful or failed response message returned by a receiver, analyzes the SIP BYE message when judging that the SIP BYE message is successfully sent according to the response message,

if the SIP BYE message is that the CPM user leaves the conversation, or the whole CPM conversation is ended, or the temporary SIP conversation for transmitting the CPM large message is ended and the transmission process of the large message in the conversation is ended, or the temporary SIP conversation for transmitting the CPM file is ended and the transmission process of the large message in the conversation is ended, finding out a corresponding CPM conversation historical record object;

if the SIP BYE message is the end of the temporary SIP session for transmitting the CPM large message and the end of the transmission process of the large message outside the session, finding a corresponding CPM message recording object;

if the SIP BYE message is that the temporary SIP session for transmitting the CPM file is ended and the transmission process of the file outside the session is ended, finding out a corresponding CPM file transmission history record object;

after the recording object is obtained, the related CPM session history object, CPM message recording object or CPM file transmission history object is updated according to the judgment result.

The SIP REFER message processing comprises the following steps:

the CPM participation function caches the SIP REFER message locally, after waiting for receiving a response message returned by a receiver and being successful or failed, judges that the SIP REFER message is successfully sent according To the response message, and obtains the value of a method parameter in a REFER-To header field of the SIP REFER message through the value of a CPM session identifier carried in a Request-URI:

if the value of the method parameter is BYE, writing a session state event of a removed user in a CPM session history record object, and extracting related information from the SIP REFER message for recording;

if the value of the method parameter is INVITE, a session state event inviting the user to join is written in a CPM session history object, and related information is extracted from the SIP REFER message for recording.

The SIP MESSAGE message processing includes:

the CPM participation function caches the SIP MESSAGE message locally, waits for receiving and caches a successful or failed response message returned by a receiver, and judges that the SIP MESSAGE message is successfully sent according to the response message; the SIP MESSAGE message is parsed and the message is parsed,

if the To header field of the SIP MESSAGE message carries a tag parameter, judging that the SIP MESSAGE message is a CPM session message, finding a CPM session matched with the SIP MESSAGE message, extracting related information from the SIP MESSAGE request message and writing the related information into a corresponding CPM session history record object; recording the result sent by the CPM MESSAGE according to a success or failure response MESSAGE returned by the MESSAGE MESSAGE, wherein the result is also used as a part of a CPM session history record object;

if the tag parameter in the To header field of the SIP MESSAGE message is null, it is determined that the message is an out-of-CPM session message, and after determining that the message is successfully sent according To the response message of the SIP MESSAGE message, the CPM participation function creates a new CPM message recording object, and extracts related information from the SIP MESSAGE request message for recording according To the provision of the storage format of the CPM message.

The MSRP SEND message processing comprises the following steps:

when the CPM participation function caches the MSRP SEND message locally, after waiting for receiving a successful or failed response message returned by a receiver and caching, if receiving the successful response message,

analyzing the MSRP SEND message, if the MSRP SEND message is not fragmented, finding a corresponding conversation historical record object through a receiving port number of the MSRP SEND message, and carrying out corresponding processing according to a CPM message recording process, a CPM file transmission recording process or a CPM conversation historical record process corresponding to the MSRP SEND message;

if the MSRP SEND message is a fragment, further judging whether the fragment is the last fragment and the last fragment, and assembling all the MSRP SEND message fragments belonging to a large message to form a complete MSRP SEND large message; and finding a corresponding conversation historical record object through a receiving port number of the MSRP SEND message, and carrying out corresponding processing according to a CPM message recording process, a CPM file transmission recording process or a CPM conversation historical record process corresponding to the MSRP SEND message.

The corresponding CPM message recording process comprises the following steps: acquiring the content in the MSRP SEND message, serving as the content of the CPM large message transmitted outside the session, and encapsulating the content into a corresponding CPM message recording object to form a final CPM message recording object;

the corresponding CPM file transmission recording process is processed as follows: acquiring the content in the MSRP SEND message as the content of the CPM file transmitted outside the session, and encapsulating the content into a corresponding CPM file transmission history object to form a final CPM file transmission history object;

the corresponding CPM session history process is processed as follows: and acquiring the content in the MSRP SEND message, serving as a large message or file transmitted in the CPM session, packaging the large message or file into a corresponding CPM session history record object, and updating.

The CPM participation function inserts itself as a SIP B2BUA on the signalling and media channels.

A device for realizing conversation history record in converged message service at least comprises a receiving module, a judging module and a recording module, wherein,

the receiving module is used for receiving the message, outputting the recording module and informing the judging module;

the judging module is used for receiving the notification from the receiving module, detecting whether the user starts the conversation history recording function or not, and sending a recording notification to the recording module when the conversation history recording function is started;

and the recording module is used for receiving the recording notification, analyzing the received message according to the protocol type of the received message and executing the conversation history recording function according to the analysis result.

When the protocol type of the received message is a SIP protocol message, the recording module is specifically configured to,

When the protocol type of the received message is the MSRP protocol message, the recording module is specifically configured to,

The received message is a continuous media stream data packet, and the judging module detects that the CPM session recording function is started, the device further comprises a processing module for,

recording continuous media streams of parties participating in the session, starting a media mixing function, mixing the media streams of the parties participating in the CPM session, and storing the mixed media stream data;

and after the CPM session is ended, extracting the locally cached mixed media stream data packet, coding according to the requirement of the storage format of the session history record, and then packaging the media stream object code into a CPM session history record object.

The apparatus is provided in a CPM session history function.

It can be seen from the above technical solutions that the CPM participating function receives a message, detects that a user has started a session history function, parses the received message according to a protocol type of the received message, and executes the session history function according to a parsing result. The processing logic of the conversation history recording function of the CPM participation function of the invention realizes the recording function of the history of message, file transmission and conversation interaction in the integrated message service environment.

Drawings

Fig. 1 is a schematic diagram of a relationship between a CPM session and a CPM message, a CPM file transfer, a CPM session, and a relationship between a CPM session history and a CPM message record, a CPM file transfer history, and a CPM session history;

FIG. 2 is a flow chart illustrating a method for implementing conversation history according to the present invention;

FIG. 3 is a flow chart of processing SIP INVITE messages;

FIG. 4 is a flowchart of an implementation of step 3031 in FIG. 3;

FIG. 5 is a flowchart of an implementation of step 3032 in FIG. 3;

FIG. 6 is a flowchart of an implementation of step 3033 in FIG. 3;

fig. 7 is a flowchart of processing a SIP BYE message;

fig. 8 is a flowchart of processing a SIP REFER message;

FIG. 9 is a flow chart of processing SIP MESSAGE messages;

FIG. 10 is a flow diagram of the processing of an MSRP SEND message;

FIG. 11 is a schematic diagram of an apparatus for implementing conversation history recording according to the present invention.

Detailed Description

Fig. 1 is a schematic diagram of a relationship between a CPM session and a CPM message, a CPM file transfer, and a CPM session, and a relationship between a CPM session history and a CPM message record, a CPM file transfer history, and a CPM session history, as shown in fig. 1:

the CPM session history recording function is actually to record CPM messages, CPM file transfers, and CPM sessions that are interacted during a CPM session. In order to implement the session history recording function, a CPM functional entity needs to be located on both the signaling plane and the media plane in the communication process, as a Back-to-Back User Agent (B2 BUA) to receive and send all signaling messages and media messages in the communication process, and extract information to be recorded from the signaling messages and media messages by parsing, and record the information according to a certain format: one piece of CPM message interacted outside the CPM session is recorded as a CPM message recording object, one CPM file transmitted outside the CPM session is recorded as a CPM file transmission history object, and one piece of CPM session is recorded as a CPM session history object. The CPM participation function server completes the above-described session history recording function, and submits these recorded objects to the CPM message storage server for permanent storage.

The CPM message records an object, and stores a CPM message interacted outside a CPM session. CPM messages are of two types: a Page-Mode (Page-Mode) and a Large Message Mode (Large Message Mode). Among them, the paging mode CPM message is transmitted through the SIP signaling plane by using the SIP MESSAGE method defined in [ RFC 3428], that is, the size of the paging mode CPM message is limited, i.e., 1300 bytes cannot be exceeded, and if so, the content of the message is not put into the SIP MESSAGE message body, but is transmitted using the large message mode CPM message. The large message mode CPM message is a single CPM message (for example, carrying multimedia content) containing large data volume information sent by the MSRP protocol ([ RFC 4975]), and if necessary, segmented transmission may be performed, so before sending the large message mode CPM message, a temporary SIP session is first requested to be established between communicating parties through SIP INVITE to negotiate establishment of an MSRP media channel, and after the temporary SIP session is successfully established, the actual message content can be requested to be sent through the MSRP SEND. After the large messaging is over, the temporary SIP session will be torn down immediately.

The CPM file transfer history object stores a CPM file, such as a text document, a picture, an audio file, a video file, or an application, etc., which may carry multimedia content, transferred outside the CPM session. The transmission process of the CPM file is similar to the sending process of the CPM message in the large message mode, and a temporary SIP session is first requested to be established between the sender and the receiver of the file through SIP INVITE to negotiate the establishment of an MSRP media channel. The recipient needs to explicitly accept or reject the transmission request of the CPM file. If the temporary SIP session is successfully established, the actual content of the CPM file is sent using an MSRP SEND request message (segmented delivery is also possible, if necessary). After the CPM file transfer is finished, the temporary SIP session will be torn down immediately.

The CPM session history object stores interaction history information during a CPM session at one time, and should include four types of information: CPM session state change information, CPM messages (and possibly contained media objects) that are interacted with in a CPM session, CPM files that are transmitted in a CPM session, and continuous media stream objects (e.g., audio/video call segments) that are interacted with in the CPM session. Wherein,

the CPM session state information is used for describing the whole development change process of the whole CPM session from creation to termination, and comprises the following six types of session state change event information: CPM session creation event related information (SIP INVITE request message and related response message), CPM session participant leaving session event related information (SIP BYE request and related response message), CPM session participant removed event information from CPM session (SIP REFER request and related response message), a CPM user joining CPM session event information (SIP INVITE request and related response message), inviting other CPM session participants to join the CPM session event information (SIP REFER request and related response message), and CPM session ending event information (SIP BYE request and related response message).

It can be seen that in order to form a CPM session history, the CPM session history function needs to process many different types of messages from the signaling plane and the media plane, and understand the semantics represented by the messages according to the context of the session, so as to record the session process. Because the processing logic is very complex, the realization of the conversation history function cannot be well realized only by reusing the existing mechanism, and therefore, a new and effective mechanism needs to be provided on the basis of the existing mechanism to realize the conversation history function.

In the converged messaging service communication environment, in order to record all communication interaction processes of a user participating in a conversation, the invention sets a CPM participation function to be simultaneously positioned on a signaling channel and a media channel of the CPM conversation, all CPM messages or CPM conversation information related to the CPM conversation pass through the CPM participation function, the CPM participation function checks the messages, executes corresponding logic functions, and completes the recording functions of corresponding CPM messages, CPM file transmission history and CPM conversation history according to different semantics represented by different messages in different context environments.

The protocol messages related to the CPM session history mainly include: SIP INVITE request and its related reply message, SIP REFER request and its related reply message, SIP BYE request and its related reply message, SIP MESSAGE request and its related reply message, MSRP SEND and its related reply message. These messages perform different functions by carrying different header contents in different contexts, such as: SIP INVITE message can initiate a CPM session, or establish MSRP channel for sending large message mode CPM message, or apply for adding an ongoing CPM session initiation session establishment process for a certain CPM user, so in the invention, the actual semantics of the message is known by judging the related header fields carried by different messages, and the related message recording or session history recording function is completed accordingly.

To perform the session history function, the CPM participation function also inserts itself on both the signaling and media channels of the CPM session and performs the B2BUA function. For a signaling plane, each time a signaling message is received, a CPM participation function first executes an applicable CPM service processing logic, and then determines whether a user starts a session history recording function, if the user starts the session recording function, the CPM participation function needs to determine actual semantics represented by the message in a session process according to a session context, and updates a related message recording object or a session history recording object. If the user does not turn on the session history function, the CPM participation function forwards the signaling message according to the processing logic of the CPM service. For the user plane, once the user starts the session recording function, the CPM participating function needs to cache and record the media stream transmitted on the relevant media channel, and after the session is ended, encapsulate the cached media stream into the session history object to form a complete session history object.

The scheme of the present invention is described in detail below with reference to examples.

Fig. 2 is a schematic flow chart of a method for implementing conversation history according to the present invention, as shown in fig. 2, including:

step 200-201: the CPM participation function receives a message, detects whether the user starts the session history function, and if the user starts the session history function, the CPM participation function starts to execute the session history function, and then the step 202 is executed; otherwise step 207 is entered.

Step 202: checking the protocol type of the received message, and if the message is a SIP protocol message, entering step 203; if it is an MSRP protocol message, step 205 is entered.

Step 203, step 2044: calling an SIP protocol stack for analysis, and entering step 2041 to perform specific analysis when the analyzed result is SIP INVITE, and ending; when the analyzed result is SIP BYE, the step 2042 is entered for specific analysis, and the operation is finished; when the analyzed result is the SIP REFER, the step 2043 is entered for specific analysis, and the process is ended; when the result of the analysis is SIP MESSAGE, the process proceeds to step 2044 to perform specific analysis, and the process is ended.

Step 205 to step 206: and calling the MSRP protocol stack for analysis, and when the MSRP SEND is obtained through analysis, specifically analyzing the MSRP SEND and ending.

Step 207: the received message is forwarded.

If the CPM session history recording function is started and a continuous media stream data packet is received, the CPM participation function records the continuous media streams of all parties participating in the session, and starts a media mixing function to mix the media streams of all parties participating in the CPM session and store the mixed media stream data. When the CPM session is ended, the CPM participation function extracts the locally cached mixed media stream data packet, codes the media stream data packet according to the requirement of the storage format of the session history record, and then encapsulates the media stream object code into a CPM session history record object.

Because the processing logic of the session history recording function in the converged messaging service communication environment is very complex, and no mature session history mechanism can be used for reference in the existing messaging service, the technical scheme of the invention makes up the blank of the processing logic of the session history recording function in the converged messaging service communication environment.

As shown in fig. 11, the present invention may be arranged in a CPM session history function, and at least includes a receiving module, a determining module, and a recording module, where,

When the protocol type of the received message is the SIP protocol message, the recording module is specifically configured to invoke a SIP protocol stack to analyze the received SIP protocol message, and when the analyzed result is SIP INVITE, perform SIP INVITE message processing; when the analyzed result is SIP BYE, SIP BYE message processing is carried out; when the analyzed result is SIP REFER, SIP REFER message processing is carried out; when the analyzed result is SIP MESSAGE, the sip message processing is performed.

And when the protocol type of the received message is the MSRP protocol message, the recording module is specifically used for calling the MSRP protocol stack to analyze the received MSRP protocol message, and when the message is analyzed to be MSRPSEND, the MSRP SEND message is processed.

When the received message is a continuous media stream data packet and the judging module detects that the CPM session recording function is started, the device also comprises a processing module, wherein the processing module is used for recording continuous media streams of all parties participating in the session, starting a media mixing function, mixing the media streams of all parties participating in the CPM session, and storing the mixed media stream data; and after the CPM session is ended, extracting the locally cached mixed media stream data packet, coding according to the requirement of the storage format of the session history record, and then packaging the media stream object code into a CPM session history record object.

In the following, specific analysis will be performed on the five request messages related to the session status that will appear in the CPM session, and attention is paid to processing logic related to the history recording function of the CPM participation function, that is, after the default CPM participation function has verified the validity of these messages and completed the related CPM service processing logic, on the premise that the CPM user has opened the session history recording function, how to complete the processing logic related to the recording function of the CPM session history.

Fig. 3 is a flow chart of processing SIP INVITE, as shown in fig. 3, including:

step 300 to step 301: when the CPM participation function receives an SIP INVITE message, the SIP INVITE message is firstly cached locally, and after a response message of success or failure returned by the receiving party is received and cached, the CPM participation function starts to execute the conversation history information recording function.

Step 302 to step 3033: the CPM participation function checks a CPM feature tag carried in an Accept-Contact header field and a Contact header field, if the CPM feature tag indicates that the message is a temporary SIP session establishment request message established for transmitting a CPM large message, the step 3031 is executed; if the CPM feature tag indicates that it is an establishment request message for establishing a temporary SIP session for CPM file transmission, perform step 3032; if the CPM feature tag indicates that this is a SIP session setup request message related to a CPM session event, step 3033 is performed.

Fig. 4 is a flowchart of an implementation of step 3031 in fig. 3, as shown in fig. 4, including:

step 400: judging whether the message is a request message for establishing a temporary SIP session for large message transmission in the CPM session or a request message for establishing a temporary SIP session for large message transmission outside the CPM session, if the message is a large message in the CPM session, entering a step 404, and if not, entering a step 401.

In this step, the judging method is as follows: checking SIP INVITE whether the To header field of the message carries tag parameter, if it carries tag parameter, it indicates the establishment request message for establishing temporary SIP session for large message transmission in CPM session; and if the tag parameter is not carried, indicating that the establishing request message of the temporary SIP session is established for large message transmission outside the CPM session.

Step 401: judging whether the SIP temporary session is established successfully or not according to the response message, and if so, entering step 402; otherwise step 403 is entered.

In this step, a determination is made according to a response message (SIP 200OK or failure response) corresponding to the received INVITE message, and if the received response message is the SIP 200OK response message, it indicates that the SIP session is successfully established, and if the received response message is the failure response, it indicates that the SIP session is failed to be established.

Step 402: the CPM participation function creates a CPM message recording object, and extracts related information (From header field, To header field, etc.) From the SIP INVITE request message for recording, as specified by the unified storage format of the CPM message. Step 407 is then entered.

Step 403: no recording is made. The CPM participation function discards the INVITE message, does not make a record, and returns a failure response message. And (6) ending.

Step 404-406: searching a CPM session to which the CPM large message belongs by calculating and comparing the Dialog-ID, finding a session history record object of the corresponding CPM session, and extracting relevant information from the INVITE message for recording; according to the response message of the INVITE request regarding success or failure, recording is performed in the CPM session history object. Step 407 is then entered.

The method specifically comprises the following steps: calculating Dialog-ID (namely obtaining values of tag parameters in a Call-ID header field, a From header field and a To header field) according To the related description in [ RFC 3261], comparing the Dialog-ID with the Dialog-ID in each ongoing CPM session state parameter stored by the CPM participation function, and finding the CPM session To which the large message in the CPM session belongs; finding out a CPM session history object corresponding to the matched CPM session, extracting relevant information from the SIP INVITE request message and writing the relevant information into the corresponding CPM session history object; according to the response message of success or failure returned to the INVITE message, the result of success or failure of SIP session establishment is recorded, and is also used as a part of the CPM session history object.

Step 407: waiting for receiving the MSRP SEND message at the port of the designated MSRP media channel.

In this step, in order to perform the session history, the CPM participation function needs to be inserted into the signaling and media channel as a B2BUA, that is, the CPM participation function will respectively represent the receiver and the sender to negotiate a media channel port, so as to realize inserting itself into the media channel. The CPM participation function will wait on the negotiated MSRP communication port to receive MSRP SEND messages to receive CPM large messages.

Fig. 5 is a flowchart of an implementation of step 3032 in fig. 3, as shown in fig. 5, including:

step 500: judging whether the message is a request message for establishing a temporary SIP session for file transmission in the CPM session or a request message for establishing a temporary SIP session for file transmission outside the CPM session, if the message is file transmission in the CPM session, entering step 504, otherwise, entering step 501.

In this step, the judging method is as follows: checking SIP INVITE whether the To header field of the message carries tag parameter, if it carries tag parameter, it indicates the establishment request message for establishing temporary SIP session for file transmission in CPM session; and if the tag parameter is not carried, indicating that the establishing request message of the temporary SIP session is established for file transmission outside the CPM session.

Step 501: judging whether the SIP temporary session is established successfully or not according to the response message, and if so, entering step 502; otherwise step 503 is entered.

Step 502: the CPM participation function creates a CPM file transfer history object, and extracts and records relevant information (From header field, To header field, etc.) From the SIP INVITE request message as specified by the unified storage format of the CPM file transfer history. Then step 507 is entered.

Step 503: no recording is made. The CPM participation function discards the INVITE message, does not make a record, and returns a failure response message. And (6) ending.

Step 504 to step 506: searching the CPM session to which the CPM file transmission belongs by calculating and comparing the Dialog-ID, searching a session history record object of the corresponding CPM session, and extracting relevant information from the INVITE message for recording; according to the response message of the INVITE request regarding success or failure, recording is performed in the CPM session history object. Then step 507 is entered.

The method specifically comprises the following steps: calculating the Dialog-ID (namely obtaining the values of tag parameters in a Call-ID header field, a From header field and a To header field) according To the related description in the RFC 3261, comparing the Dialog-ID with the Dialog-ID in each ongoing CPM session state parameter stored by the CPM participation function, and finding the CPM session To which the CPM file transmission belongs; finding out a CPM session history object corresponding to the matched CPM session, extracting relevant information from the SIP INVITE request message and writing the relevant information into the corresponding CPM session history object; according to the response message of success or failure returned to the INVITE message, the result of success or failure of SIP session establishment is recorded, and is also used as a part of the CPM session history object.

Step 507: waiting for receiving the MSRP SEND message at the port of the designated MSRP media channel.

In this step, in order to perform the session history, the CPM participation function needs to be inserted into the signaling and media channel as a B2BUA, that is, the CPM participation function will respectively represent the receiver and the sender to negotiate a media channel port, so as to realize inserting itself into the media channel. The CPM participation function will wait on the negotiated MSRP communication port for receiving the MSRP SEND message to receive the CPM file.

Fig. 6 is a flowchart of an implementation of step 3033 in fig. 3, as shown in fig. 4, including:

step 600: judging whether the SIP session establishment request message related to the CPM session event is a session establishment request message initiated for establishing a new CPM session or a session joining request message initiated for applying for joining an ongoing CPM session by a certain CPM user, if the SIP session establishment request message is the session establishment request message, entering step 605; if the latter, step 601 is entered.

In this step, the judging method is as follows: checking SIP INVITE whether the To header of message carries tag parameter, if it carries tag parameter, it indicates that the SIP session establishment request message related To CPM session event is a session establishment request message initiated for establishing a new CPM session; if the tag parameter is not carried (namely null), the SIP session establishment request message related to the CPM session event is indicated to be a session joining request message initiated by a certain CPM user for applying to join an ongoing CPM session.

Further, the Request-URI of the Request message is checked SIP INVITE,

if the value of the Request-URI is a CPM session identifier, indicating SIP INVITE that the Request message is a session joining Request message initiated by a certain CPM user for applying for joining an ongoing CPM session;

if the value of the Request-URI is the address of the CPM control function and the tag parameter in the To header field is null, indicating SIP INVITE that the Request message is a session establishment Request message initiated for an ongoing Ad-hoc group CPM session;

if the value of the Request-URI is the address of the CPM user and the tag parameter in the To header field is null, indicating that the SIP INVITE Request message is a session establishment Request message initiated for establishing a new 1-1CPM session;

if the value of the Request-URI is the address of the CPM group and the tag parameter in the To header field is null, it indicates SIP INVITE that the Request message is a session establishment Request message initiated for establishing a new predefined group CPM session.

Step 601 to step 604: a session Request message initiated by a certain CPM user for applying for joining an ongoing CPM session is used for finding a corresponding CPM session history record object through a CPM session identifier indicated in a Request-URI; extracting and recording related information from the SIP INVITE message according to the specification of a session history record storage format; according to a response message of success or failure returned to the INVITE message, the result of the request to join the CPM session event is recorded, also as a part of the CPM session history object. And (6) ending.

Step 605 to step 607: the method comprises the steps that a session establishment request message is initiated for establishing a new CPM session, and a CPM participation function creates a new CPM session history record object in a local storage space; extracting relevant information from the SIP INVITE message and recording the information according to the storage format of the CPM session history record; according to a response message of success or failure returned to the INVITE message, the result of the CPM session creation event is recorded, also as a part of the CPM session history object.

Fig. 7 is a flowchart of processing a SIP BYE message, as shown in fig. 7, including:

step 700 to step 701: when the CPM participation function receives an SIP BYE message, the SIP BYE message is cached locally, and after a successful or failed response message returned by a receiver is received and cached, the conversation history information recording function is started to be executed.

Step 702: judging whether the SIP BYE message is successfully sent or not according to the response message, if the received SIP 200OK response message indicates that the SIP BYE message is successfully transmitted, continuing to execute the step 703; if a SIP failure response message is received indicating that the SIP BYE message was not delivered, step 714 is performed.

Step 703 to step 709: parsing the SIP BYE message, finding the SIP session associated with the SIP BYE message by calculating the Dialog-ID, and obtaining the semantics represented by the SIP session if the meaning of the SIP BYE message is:

if the CPM user leaves the session, or the whole CPM session is ended, or the temporary SIP session for transmitting the CPM large message is ended and the transmission process of the large message in the session is ended, or the temporary SIP session for transmitting the CPM file is ended and the transmission process of the large message in the session is ended, then go to step 712;

if the temporary SIP session for transmitting the CPM large message is finished and the transmission process for the extra-session large message is finished, go to step 710;

if the temporary SIP session for transferring the CPM file is ended and the transfer process for the out-of-session file is ended, step 711 is entered.

Step 710: finds a corresponding CPM message recording object and proceeds to step 713.

Step 711: a corresponding CPM file transmission history object is found and proceeds to step 713.

Step 712: finds a corresponding CPM session history object, and proceeds to step 713.

Step 713: and updating the related CPM session history object, CPM message recording object or CPM file transmission history object according to the judgment result. And if the whole CPM session is ended, the CPM participation function packages the cached continuous media interacted in the CPM session process into a related CPM session history object according to a uniform storage format, and finally completes the assembly work of the CPM session history object and submits the CPM session history object to a message storage server. And (6) ending.

Step 714: the SIP BYE message is discarded and a failure response message is returned.

Fig. 8 is a flowchart of processing a SIP REFER message, as shown in fig. 8, including:

step 800 to step 801: when the CPM participation function receives an SIP REFER message, the SIP REFER message is firstly cached locally, and after a successful or failed response message returned by a receiving party is received and cached, the conversation history information recording function is started to be executed.

Step 802: judging whether the SIP REFER message is successfully sent according to the response message, if the received SIP 200OK response message indicates that the SIP REFER message is successfully transmitted, entering step 803; if a SIP failure response message is received, indicating that the SIP REFER message was not delivered, step 808 is entered.

Step 803 to step 807: analyzing the SIP REFER message, and acquiring the value of a "method" parameter in a header field of the SIP REFER message REFER-To through the value of the CPM session identifier carried in the Request-URI:

if the value of the "method" parameter is "BYE", which indicates that the SIP REFER message wishes to remove some users from the specified CPM session, writing a session state event of "removed user" in the CPM session history object, and extracting relevant information from the SIP REFER message for recording; and (6) ending.

If the value of the "method" parameter is "INVITE", indicating that the SIP REFER message wishes to INVITE some users to join in a specified CPM session, a session state event of "INVITE user to join" is written in the CPM session history object, and related information is extracted from the SIP REFER message for recording. And (6) ending.

Step 808: the message is discarded and a failure reply message is returned.

Fig. 9 is a flowchart of processing SIP MESSAGE messages, as shown in fig. 9, including:

step 900 to step 901: when the CPM participation function receives an SIP MESSAGE message, the SIP MESSAGE message is firstly cached locally, and after a response message of success or failure returned by the receiving party is received and cached, the CPM participation function starts to execute the conversation history information recording function.

Similarly, it is determined whether the SIP MESSAGE message was successfully sent according to the response message, and if the SIP 200OK response message is received, it indicates that the SIP MESSAGE message was successfully transmitted, step 902 is performed; if a SIP failure reply message is received indicating that the SIP MESSAGE message failed to be delivered, the message is discarded and a failure reply message is returned.

Step 902: analyzing SIP MESSAGE whether a To header field of the message carries a tag parameter, if so, judging that the SIP MESSAGE message is a CPM session message, and executing step 903; if the tag parameter is null, it is determined to be an out-of-CPM session message, and step 907 is performed.

Step 903 to step 906: if the SIP MESSAGE message is a CPM message in a CPM session, then calculate the Dialog-ID (i.e. obtain the values of tag parameters in the Call-ID header field, From header field, and To header field) according To the relevant description in [ RFC 3261], compare the Dialog-ID with the Dialog-ID in each ongoing CPM session state parameter stored by the CPM participation function, and find the CPM session To which the CPM message belongs:

if a matching CPM session is found, extracting relevant information from the SIP MESSAGE request message and writing the information into a corresponding CPM session history object; recording a result sent by the CPM message according to a response message of success or failure returned by the CPM message, wherein the result is also used as a part of a CPM session history record object; and (6) ending.

And if no matching CPM session is found, returning an error message and ending.

Step 907 to step 911: the SIP MESSAGE message is a CPM message outside the CPM session, and whether the message is successfully sent is determined according to a response message to the SIP MESSAGE message:

if the message is successfully sent, the CPM participation function creates a CPM message recording object, and extracts related information from the SIP MESSAGE request message for recording according to the provision of the storage format of the CPM message; if the message transmission fails, the CPM participating function does not make any recording, discards the message, and returns an error response.

Fig. 10 is a flowchart of processing an MSRP SEND message, as shown in fig. 10, including:

step 1000 to step 1001: when the CPM participation function receives an MSRP SEND message, the MSRP SEND message is firstly cached locally, and after a successful or failed response message returned by a receiver is received and cached, the conversation history information recording function is started to be executed.

Step 1002: judging whether the MSRP SEND message is successfully sent or not according to the response message, if the MSRP 200OK response message is received, indicating that the MSRP SEND message is successfully transmitted, entering step 1003; if an MSRP failure response message is received, indicating that the MSRP SEND message failed to be delivered, step 1012 is entered.

Step 1003 to step 1004: analyzing the MSRP SEND message, according to the flow defined in [ RFC 4975], judging whether the MSRP SEND message is transmitted in segments by checking the value of a 'Byte-Range' header, if so, the MSRP SEND message is a fragment, further judging whether the fragment is the last fragment, if so, indicating that all the fragments are completely received, and entering a step 1005; if not, go to step 1011.

If the MSRP SEND message is not fragmented, then the MSRP SEND message is not a fragmented transport and step 1006 is entered directly.

Step 1005: and assembling all the MSRP SEND message fragments belonging to the same large message to form a complete MSRP SEND large message.

Step 1006: and finding the corresponding conversation history record object through the receiving port number of the MSRP SEND message.

Step 1007: and judging whether the MSRP SEND message corresponds to a CPM message recording process, a CPM file transmission recording process or a CPM session history recording process. If the message transmitted by the MSRP SEND is a CPM session outer large message, then step 1008 is entered; if the MSRP SEND transmits the CPM out-of-session file, the step 1009 is entered; if the MSRP SEND transmits a CPM large message or a CPM file in the session, step 1010 is entered.

Step 1008: acquiring the content in the MSRP SEND message as the content of the CPM large message transmitted outside the session, and encapsulating the content into a corresponding CPM message recording object to form a final CPM message recording object; and (6) ending.

Step 1009: acquiring the content in the MSRP SEND message as the content of the CPM file transmitted outside the session, and encapsulating the content into a corresponding CPM file transmission history object to form a final CPM file transmission history object; and (6) ending.

Step 1010: acquiring the content in the MSRP SEND message, serving as a large message or file transmitted in the CPM session, packaging the large message or file into a corresponding CPM session history record object, and updating the large message or file; and (6) ending.

Step 1011: and continuing to wait for other fragments of the rest of the MSRP SEND message and returning to the step 1000.

Step 1012: the message is discarded and a failure reply message is returned.

By the method of the invention, it can be seen that:

(1) once the CPM participation function activates the session history function, the CPM participation function will be located on both the signaling channel and the media channel to classify the messages related to the session status. The CPM processes SIP INVITE, SIP REFER, SIP MESSAGE, SIP 200OK, SIP failure response message, etc. on the signaling plane, and judges the meaning represented by the message according to the context, extracts key information from the relevant request message and response message and records the key information in a uniform format, rather than storing the messages as they are.

(2) For the SIP INVITE message, since it may represent three different session events, i.e. sending a CPM large message, transmitting a CPM file, or establishing a CPM session, the CPM participation function of the present invention determines which event belongs to by parsing a CPM feature tag carried by an INVITE message "Accepted-Contact" header field, so as to determine that CPM message recording or CPM file transmission recording or CPM session history recording should be performed.

(3) The CPM participation function executes the conversation history recording function after waiting for obtaining the response message returned by the receiver, and executes the corresponding recording function if the message is successfully sent; if the message transmission fails and is a message outside the session, directly discarding the message; if the message fails to be sent and is a session-related message, the semantics represented by the message are acquired and recorded in the session history record.

(4) After receiving the SIP 200OK response message, the CPM participation function determines the actual semantics represented by the successful response message, if the large message transmission media channel is indicated to be successfully established, the CPM participation function starts an MSRP media plane and prepares to receive an MSRP SEND message and records the MSRP SEND message; if the CPM file transmission media channel is indicated to be successfully established, the CPM participation function starts a corresponding media plane to prepare for receiving and recording an MSRP SEND message; if the CPM session is successfully established, the CPM participation function starts a corresponding continuous media stream plane to prepare for receiving the continuous media stream, and the media streams of all parties participating in the session are mixed and recorded.

(5) After receiving the SIP REFER message, the CPM participation function records corresponding session state change information after judging whether to add a user operation or remove the user operation.

(6) After receiving the SIP BYE message, the CPM participation function determines the semantics represented by the BYE message: if the CPM session is ended, encapsulating all the content cached for the session into a complete session history record by the CPM participation function; if the transmission of the CPM large message or the CPM file outside the session is finished, the CPM participation function packages the related content into a complete CPM message record or a CPM file transmission history record; and if the transmission of the CPM message or the CPM file in the session is finished or the CPM user leaves the session, updating the session state information of the corresponding CPM session.

The processing logic of the conversation history recording function of the CPM participation function of the invention realizes the recording function of the history of message and conversation interaction in the converged message service environment.

The above description is only exemplary of the present invention and should not be taken as limiting the scope of the present invention, and any modifications, equivalents, improvements, etc. that are within the spirit and principle of the present invention should be included in the present invention.

Claims

1. A method for realizing conversation history record in converged message service is characterized by comprising the following steps:

2. The method of claim 1, wherein the received message is a SIP protocol message, and wherein parsing the received message and performing a conversation history function according to the parsed result comprises:

3. The method of claim 1, wherein the received message is of a protocol type of MSRP protocol message, and wherein parsing the received message and performing the conversation history function according to the parsed result comprises:

4. The method according to claim 1, 2 or 3, wherein if the continuous media stream packets are received and it is detected that the CPM session recording function is turned on, the method further comprises:

5. The method of claim 2, wherein the SIP INVITE message processing comprises:

6. The method of claim 5, wherein the processing of the temporary SIP session establishment request message established for CPM large message transmission comprises:

7. The method of claim 5, wherein the processing of the temporary SIP session establishment request message established for CPM file transfer comprises:

8. The method of claim 5, wherein the processing of the SIP Session setup request message related to the CPM session event comprises:

9. The method of claim 8, further comprising: the Request-URI of the Request message is checked SIP INVITE,

10. The method of claim 2, wherein the SIP BYE message processing comprises:

11. The method of claim 2, wherein the SIP REFER message processing comprises:

12. The method of claim 2, wherein the SIP MESSAGE message processing comprises:

13. The method of claim 2, wherein the MSRP SEND message processing comprises:

14. The method of claim 13, wherein the corresponding CPM message recording procedure is processed by: acquiring the content in the MSRP SEND message, serving as the content of the CPM large message transmitted outside the session, and encapsulating the content into a corresponding CPM message recording object to form a final CPM message recording object;

15. The method according to any of claims 1-14, wherein the CPM participation function inserts itself as a SIP B2BUA on signaling and media channels.

16. A device for realizing conversation history record in converged message service is characterized by at least comprising a receiving module, a judging module and a recording module, wherein,

17. The apparatus according to claim 16, wherein the recording module is specifically configured to, when the protocol type of the received message is a SIP protocol message,

18. The apparatus according to claim 16, wherein the recording module is specifically configured to, when the protocol type of the received message is an MSRP protocol message,

19. The apparatus according to any one of claims 16 to 18, wherein the received message is a continuous media stream packet, and the determining module detects that a CPM session recording function is turned on, the apparatus further comprising a processing module configured to,

20. The apparatus of claim 19, wherein the apparatus is disposed in a CPM session history function.