WO2015058648A1 - 基于ip电话的留言业务处理方法及装置 - Google Patents

基于ip电话的留言业务处理方法及装置 Download PDF

Info

Publication number
WO2015058648A1
WO2015058648A1 PCT/CN2014/088675 CN2014088675W WO2015058648A1 WO 2015058648 A1 WO2015058648 A1 WO 2015058648A1 CN 2014088675 W CN2014088675 W CN 2014088675W WO 2015058648 A1 WO2015058648 A1 WO 2015058648A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
service server
message
message content
information
Prior art date
Application number
PCT/CN2014/088675
Other languages
English (en)
French (fr)
Inventor
白天
宋秀娟
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2015058648A1 publication Critical patent/WO2015058648A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • the present invention relates to the field of communications, and in particular to a message service processing method and apparatus based on an Internet Protocol (IP) telephone.
  • IP Internet Protocol
  • IP telephony is a new type of telephony communication via the Internet or other networks that use IP technology. With the increasing popularity of the Internet and the surge in cross-border communications, IP telephony has also been used in long-distance telephony. As the competition of communication companies in major cities around the world has intensified, and the telecommunications laws and regulations of various countries have been loosened, IP telephony has also begun to be applied to fixed-line communications. Its low call cost, low construction cost, easy expansion and increasingly good call quality are the main reasons. The characteristics are regarded by current international telecom enterprises as a strong competitor of traditional telecommunication services.
  • IP Multimedia Subsystem The usual form of IP telephony is voice communication using the Internet. Many operators deploy a Multimedia Subsystem (IMS) network to support IP calls.
  • the IP Multimedia Subsystem is a subsystem supporting IP multimedia services proposed in the 3rd Generation Partnership Project (3GPP) Release 5 version standard. It is based on the Session Initiation Protocol (SIP) system. SIP is a text-based signaling protocol that works in client/server mode. IMS uses SIP call control mechanisms to create, manage, and terminate various types of Multimedia services, which include IP call services.
  • the existing IP call solution has the following problems: In the process of media transmission after the call is established, if the party (assuming B) is dropped due to network problems, the call is interrupted, B The media content of the subsequent transmission of A can no longer be obtained. If the media content that needs to be transmitted after A (that is, after B is dropped) is very important to both A and B and has real-time characteristics (that is, it cannot be copied if it is missed), it will bring great inconvenience to A and B.
  • the present invention provides a message service processing method and device based on the IP phone to solve at least the above problem. .
  • a message service processing method based on an Internet Protocol IP phone including: monitoring a media transmission state of a first terminal and a second terminal during a call; and monitoring the second terminal and When the media transmission status of the service server is interrupted, the message content transmitted by the first terminal is continuously received by the service server; and the received message content is sent to the second terminal by the service server.
  • the method before the receiving, by the foregoing service server, the message content transmitted by the first terminal, the method includes: sending, by the service server, a notification message to the first terminal, where the notification message carries a message for prompting whether the first terminal performs The information of the message is determined according to the prompt information, whether the first terminal continues to transmit the message content, wherein, when the determination is yes, the first terminal transmits the message content to the service server.
  • the method before the receiving, by the foregoing service server, the message content transmitted by the first terminal, the method includes: sending, by using the second terminal, a notification message to the service server, where the notification message carries a message for prompting whether the first terminal performs The information of the message is determined according to the prompt information, whether the first terminal continues to transmit the message content, wherein, when the determination is yes, the first terminal transmits the message content to the service server.
  • the receiving, by the service server, the message content transmitted by the first terminal includes: saving the received message content by using the service server; and when determining that the first terminal transmission ends, packaging the received message content into a specified Formatted information; the above information obtained by encapsulation is sent to the first terminal.
  • the information of the received message content is encapsulated into the information of the specified format, including: saving the received message content as a file and generating link information of a uniform resource locator URL, wherein the link information is required to be sent to the second terminal.
  • the message sent is a uniform resource locator URL, wherein the link information is required to be sent to the second terminal.
  • the saving of the received message content by the service server includes: saving, by the service server, all the message content received by the second terminal after sending the last keep-alive message, wherein the keep-alive message is And the service signaling sent by the second terminal to the service server every predetermined time period during the media transmission process, where the service signaling is used to notify the service server that the second terminal is in an online state.
  • a message service processing apparatus based on an Internet Protocol IP telephone
  • a monitoring module configured to monitor a media transmission state of a first terminal and a second terminal during a call
  • a receiving module And being configured to continue to receive the message content transmitted by the first terminal by using the service server when monitoring that the media transmission status of the second terminal and the service server is interrupted
  • the first sending module is configured to receive the foregoing by the service server.
  • the message content is sent to the second terminal.
  • the foregoing apparatus includes: a second sending module, configured to send, by using the service server, a notification message to the first terminal, where the notification message carries information for prompting whether the first terminal performs a message; And the module is configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, when the determination is yes, the first terminal transmits the message content to the service server.
  • a second sending module configured to send, by using the service server, a notification message to the first terminal, where the notification message carries information for prompting whether the first terminal performs a message
  • the module is configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, when the determination is yes, the first terminal transmits the message content to the service server.
  • the foregoing apparatus includes: a third sending module, configured to send, by using the second terminal, a notification message to the service server, where the notification message carries information for prompting whether the first terminal performs a message; And the module is configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, when the determination is yes, the first terminal transmits the message content to the service server.
  • a third sending module configured to send, by using the second terminal, a notification message to the service server, where the notification message carries information for prompting whether the first terminal performs a message
  • the module is configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, when the determination is yes, the first terminal transmits the message content to the service server.
  • the receiving module includes: a saving unit configured to save the received message content by using the service server; and the encapsulating unit is configured to, when determining that the first terminal transmits the end, encapsulate the received message content into a specified format
  • the sending unit is configured to send the foregoing information obtained by the encapsulation to the first terminal.
  • the service server when the media transmission state interruption of the second terminal is detected, the service server continues to receive the message content transmitted by the first terminal, and then the technical problem is transmitted to the second terminal by the service server, thereby solving the related problem.
  • the interrupter when the call at one end of the call is interrupted, the interrupter cannot continue to receive the message content transmitted by the peer end, which can effectively improve the application reliability and improve the system resource utilization.
  • FIG. 1 is a flowchart of a method for processing a message service based on an IP phone according to an embodiment of the present invention
  • FIG. 2 is a structural block diagram of a message service processing apparatus based on an IP telephone according to an embodiment of the present invention
  • FIG. 3 is a block diagram showing another structure of a message service processing apparatus based on an IP telephone according to an embodiment of the present invention
  • FIG. 4 is a schematic flow chart of call setup between terminals according to a preferred embodiment of the present invention.
  • FIG. 5 is a schematic flowchart diagram of a method for processing a message service based on an IP phone according to a preferred embodiment of the present invention
  • FIG. 6 is another schematic flowchart of a method for processing a message service based on an IP phone according to a preferred embodiment of the present invention.
  • the following embodiments can be applied to a computer, such as to a PC. It can also be applied to mobile terminals currently employed in intelligent operating systems, and is not limited thereto. There are no special requirements for the operating system of a computer or mobile terminal. For example, the following embodiments can be applied to the Windows operating system.
  • FIG. 1 is a flowchart of a method for processing a message service based on an IP phone according to an embodiment of the present invention. As shown in Figure 1, the method includes the following processing steps:
  • Step S102 monitoring media transmission status of the first terminal and the second terminal during the call
  • Step S104 When it is detected that the media transmission status of the second terminal and the service server is interrupted, the message server continues to receive the message content transmitted by the first terminal; wherein the message content may include, but is not limited to, text, language, video, and image. ;
  • the authorization of the first terminal is required to enable the first terminal to continue to send the message content to the second terminal, which may be implemented by the following two methods. the way:
  • the notification message carries information for prompting the first terminal whether to leave a message; determining, according to the prompt information, whether the first terminal continues to transmit the message content, where In case, the first terminal transmits the above message content to the service server.
  • this implementation may correspond to, but is not limited to, the following scenario: the second terminal loses the network connection due to the network environment.
  • the notification message carries information for prompting the first terminal whether to leave a message; determining, according to the prompt information, whether the first terminal continues to transmit the message content, where In case, the first terminal transmits the above message content to the service server.
  • the implementation manner may correspond to, but is not limited to, the following scenario: the second terminal actively ends the call, and the second terminal again wishes to receive the message content subsequently transmitted by the first terminal.
  • Step S106 The received message content is sent to the second terminal by the service server.
  • Step S106 may be implemented by: storing, by the foregoing service server, the received message content; and when determining that the first terminal is ending, the received message content is encapsulated into information in a specified format; and the encapsulated information is sent.
  • the received message content may be saved as a file and link information of a uniform resource locator URL generated, and the link information is information that needs to be sent to the second terminal.
  • the foregoing message content that is received by the service server may include, but is not limited to, the following process: the foregoing service server saves all the message content received after the second terminal sends the last one keep-alive message, The service keeping signaling is used to notify the service server that the second terminal is in an online state, and the second terminal is in the online state.
  • a message service processing device based on the IP phone is also provided, which is used to implement the foregoing embodiments and preferred embodiments.
  • the descriptions of the modules and the preferred embodiments have been omitted. Description.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • 2 is a structural block diagram of a message service processing apparatus based on an IP telephone according to an embodiment of the present invention. As shown in Figure 2, the device comprises:
  • the monitoring module 20 is configured to monitor a media transmission status of the first terminal and the second terminal during the call;
  • the receiving module 22 is connected to the monitoring module 20, and is configured to continue to receive the message content transmitted by the first terminal through the service server when the media transmission status of the second terminal and the service server is interrupted;
  • the first sending module 24 is connected to the receiving module, and is configured to send the received message content to the second terminal by using the service server.
  • the foregoing apparatus may further include the following processing module:
  • the second sending module 26 is configured to send a notification message to the first terminal by using the service server, where the notification message carries information for prompting the first terminal whether to leave a message; the first determining module 28 is connected to the second sending module. 26, configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, if the determination is yes, the first terminal transmits the message content to the service server.
  • the foregoing apparatus may further include: a third sending module 30, configured to send, by using the second terminal, a notification message to the service server, where the notification message carries a prompt for prompting whether the first terminal performs The information of the message; the second determining module 32 is connected to the third sending module 30, and is configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, in the case of determining that the first terminal is to the service server Transfer the above message content.
  • a third sending module 30 configured to send, by using the second terminal, a notification message to the service server, where the notification message carries a prompt for prompting whether the first terminal performs The information of the message
  • the second determining module 32 is connected to the third sending module 30, and is configured to determine, according to the prompt information, whether the first terminal continues to transmit the message content, wherein, in the case of determining that the first terminal is to the service server Transfer the above message content.
  • the receiving module 22 includes: a saving unit 220 configured to save the received message content by using a service server; the encapsulating unit 222 is connected to the saving unit 220, and configured In order to determine the end of the first terminal transmission, the received message content is encapsulated into information in a specified format; the sending unit 224 is connected to the encapsulating unit 222, and configured to send the encapsulated information to the first terminal.
  • each of the above modules can be implemented by hardware.
  • a processor includes the above modules, or each of the above modules is located in one processor, or two or more modules may be located in the same processor.
  • the IP call signaling involved in this embodiment may be implemented by any existing implementation technology.
  • the SIP and the Session Description Protocol (SDP) are used for session interaction and media negotiation.
  • the real-time media transmission technology to be used in this embodiment may adopt any existing implementation technology, and a real-time transport protocol (RTP) is used in the specific implementation process.
  • the file downloading technology designed in this paper can adopt any existing implementation technology, and the Hypertext Transfer Protocol (HTTP) is adopted in the specific implementation process.
  • the call setup process of this embodiment is as shown in FIG. 4:
  • the SIP protocol is used for the call signaling, and the steps S402 to S412 complete the call setup process, and the call relationship between the terminals A and B and the service server is established according to the SIP protocol.
  • the key point of steps S402-S412 is that the carried message of terminal A in step S402 is as shown in Table 1:
  • the server After receiving the call request message of A, the server forwards the call request message to terminal B through step S404.
  • the terminal B sends a response message as shown in Table 2 to A through step S406.
  • the server records the session keep-alive time required by each of the terminal A and the terminal B through steps S402 to S406.
  • the server forwards the response of B to A through step S408, and A sends the following response to the server in step S410.
  • the server forwards the response to the terminal B through step S412.
  • terminal A and terminal B establish an IP media call through the server.
  • the bidirectional media transmission of step S414 is started.
  • the service server starts to save the media streams sent by A and B respectively through S416A and S416B.
  • a and B send the session keep-alive request message to the server through steps S418A and S418B, respectively.
  • the server After the server receives the keep-alive request message of A and B, the server starts to pass step S420A and the step.
  • the S420B covers the media streams sent by the previous A and B, that is, the server normally stores the media content of A and B for about 30 seconds.
  • the solution includes terminals and service servers that involve call and message services.
  • the main content is: When the terminals A and B perform IP-based voice or video calls and IP-based video sharing (A and B have completed the call setup process and the media data has been transmitted), the communication party ( Suppose B) The interruption of media transmission occurs. This situation is divided into the following two scenarios:
  • Scenario 1 B lost network connectivity because of the network environment.
  • the service server After the service server detects that B has lost the network connection, it sends signaling to end the call to A, and the signaling includes information indicating whether A continues to leave a message. A receives the signal and decides whether to leave a message. If A decides to leave a message, then A continues to transmit the media. Body, the service server saves the media sent by A. When A ends the sending of the media (sends the signaling of the end call to the service server), the service server saves the message of A to B as a file and generates a link information of the URL through the short message and the electronic The email is sent to B, and B downloads the message of A on the service server according to the URL.
  • Scenario 2 B actively ends the call for personal reasons, but B hopes to receive media for subsequent transmissions. Then, B sends a signaling to end the call to the server, and the signaling includes information indicating whether A continues to leave a message. After receiving the signaling, the server finds that the signaling includes information that B wishes to leave a message, and then the server saves the signaling and saves the media sent by A. The process after A receives the signaling is the same as that of scenario 1.
  • Session keep-alive means that after the call concerns of A and B are established, A and B respectively send a service signaling to the service server periodically. This signaling is called session keep-alive signaling, and its purpose is to tell the server itself. Still online.
  • the service server will refresh in real time to save A and B in 1
  • the media data in minutes (the duration of the keep-alive), that is, every minute, the business server replaces the content saved in the previous minute with the newly saved 1-minute media content.
  • B drops the line within 30 seconds after sending the keep-alive message
  • the server saves the data sent by A in one minute after sending the last keep-alive message, so that A is within 30s.
  • the transmission content will not be lost, and the data uploaded by A within 1 minute of B drop is guaranteed to be complete.
  • the subsequent service server will keep all the media data sent by A after B is disconnected, and the duration of the media data of A saved by the service server is: 60s (B starts counting after sending the last keep-alive message) +Ns (B is dropped) After 1 minute).
  • Terminal B loses the network connection for some reason. A continues to transmit the media stream to the server. The server saves the media transmitted by A to a file and generates a URL to be sent to B through SMS and email. As shown in Figure 5:
  • the service server does not receive the keep-alive message of B within 60s, and the service server sends a call termination request to terminal A through step S502.
  • the message is as shown in Table 4:
  • the call termination message sent by the service server carries the Alert-Info field, and the content is "leaving message".
  • the terminal A parses out the Alert-Info field to prompt the user whether to continue to send the media. If the user chooses to agree, then A sends an end call request response by step S502, and the message is as shown in Table 5:
  • the service server ends the receiving of the media stream transmitted by A, but continues to save the media stream of A and enters the "message mode" for terminal A.
  • the terminal A performs one-way media transmission to the service server in step S506, and the service server then saves the media sent by the terminal A through step S508.
  • the terminal A continues to send the keep-alive message in step S510 to maintain the current call. Since the service server enters the message mode for the terminal A, the service server does not overwrite the media stream of the update A after receiving the keep-alive message of the A. save.
  • a request to end the call is sent through the step S514, and the request no longer carries the Alert-Info field.
  • the service server After receiving the service server, the service server sends a response to the end call request through S516, and the response does not carry the Alert-Info field.
  • the service server generates a URL link through step S518, which is the download address of the message A of A for B.
  • A sends a text message and an email to B via step S520, the content of the text message and the email containing the connection of the URL.
  • B After receiving the SMS or email, B can download the message of A through the URL link.
  • Terminal B needs to end the call for some reason during the IP call with A, but wants to receive the content of the subsequent transmission of A.
  • the scenario implementation process is as shown in Figure 6:
  • the server Immediately after receiving the request, the server sends a response to the request to the terminal B through the step S604, and the response does not carry the Alert-Info. Terminal B ends the session normally.
  • the service server starts the same business process as scenario 1 for terminal A. I will not repeat them here.
  • the existing call message schemes are all based on the fact that the user cannot establish a call, and the above embodiments focus on the word "dynamic".
  • the signaling interaction between the server and the client can dynamically detect the need for the user to perform a message during the call, thereby implementing the message service.
  • the content of the call locally saves the space occupied by the user client, especially the video content, and the subsequent need to send the local call content file also consumes the user's network traffic. All the content of the call message in the service is stored on the server, and the service traffic monthly can be used to attract the user on the one hand and not consume the user network traffic; when the user finds that the peer is offline, the content of the call is made. During local storage, perhaps some important content has been missed.
  • the present invention automatically saves the content of the active conversation session for a long time by the server to avoid the above problem.
  • the embodiment of the present invention effectively guarantees the integrity of the IP call service information; at present, most operators deploy IMS-based IP call services, and in particular, some operators have begun to operate the IMS-based VoLTE 4G network call service.
  • the embodiment of the present invention can provide an option for the operator to maintain the continuity of the call, and is an enhanced function of the IP call service to improve the competitiveness of the operator's IP call service.
  • a storage medium is further provided, wherein the software includes the above-mentioned software, including but not limited to: an optical disk, a floppy disk, a hard disk, an erasable memory, and the like.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across multiple computing devices.
  • they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from this
  • the steps shown or described are performed sequentially, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated into a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the service server when monitoring the media transmission status interruption of the second terminal, continues to receive the message content transmitted by the first terminal, and then sends the message content to the second terminal through the service server.
  • the technical problem solves the problem in the related art that when the call at one end of the call is interrupted, the interrupter cannot continue to receive the message content transmitted by the opposite end, which can effectively improve the application reliability and improve the system resource utilization.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种基于IP电话的留言业务处理方法及装置，其中，该方法包括：监测第一终端和第二终端在呼叫过程中的媒体传输状态；在监测到第二终端与业务服务器的媒体传输状态中断时，通过业务服务器继续接收第一终端传输的留言内容；通过业务服务器将接收的留言内容发送给第二终端。采用上述技术方案，解决了相关技术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言内容等问题，能够有效提高应用可靠性，同时提高系统资源利用率。

Description

基于IP电话的留言业务处理方法及装置 技术领域
本发明涉及通信领域，具体而言，涉及一种基于互联网协议(Internet Protocol，简称为IP)电话的留言业务处理方法及装置。
背景技术
IP电话是一种通过互联网或其他使用IP技术的网络，来实现新型的电话通讯。随着互联网日渐普及，以及跨境通讯数量大幅飙升，IP电话亦被应用在长途电话业务上。由于世界各主要大城市的通信公司竞争加剧，以及各国电信相关法令松绑，IP电话也开始应用于固网通信，其低通话成本、低建设成本、易扩充性及日渐优良化的通话质量等主要特点，被目前国际电信企业看成是传统电信业务的有力竞争者。
IP电话通常的形式是利用Internet网络进行的语音通信，很多运营商都部署了多媒体子系统(Multimedia subsystem，简称为IMS)网络用来支持IP通话。IP多媒体子系统是第3代移动通信伙伴组织(3rd Gerneration Partnership Project,简称为3GPP)Release5版本标准中提出的支持IP多媒体业务的子系统。它基于会话初始协议(Session Initiation Protocol,简称为SIP)的体系，SIP是按客户端/服务器方式工作的基于文本的信令协议，IMS使用SIP呼叫控制机制来创建、管理和终结各种类型的多媒体业务，这其中就包含了IP通话业务。
现有的IP通话方案中存在以下问题：用户A和B在通话建立后进行媒体传输的过程中，如果因为网络的问题导致通话一方(假设B)掉网了，此时通话就中断了，B无法再获取A后续传输的媒体内容。如果A后续(即B掉网后)需要传输的媒体内容对A和B都非常重要并且具有实时性特征(即错过了就不可复制)，就会给A和B带来极大的不便。
针对相关技术中的上述问题，目前尚未提出有效的解决方案。
发明内容
针对相关技术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言内容等问题，本发明提供了一种基于IP电话的留言业务处理方法及装置，以至少解决上述问题。
根据本发明的一个实施例，提供了一种基于互联网协议IP电话的留言业务处理方法，包括：监测第一终端和第二终端在呼叫过程中的媒体传输状态；在监测到上述第二终端与业务服务器的媒体传输状态中断时，通过上述业务服务器继续接收上述第一终端传输的留言内容；通过上述业务服务器将接收的上述留言内容发送给上述第二终端。
优选地，通过上述业务服务器继续接收上述第一终端传输的留言内容之前，包括：通过上述业务服务器向上述第一终端发送通知消息，其中，上述通知消息中携带有用于提示上述第一终端是否进行留言的信息；根据上述提示信息确定上述第一终端是否继续传输上述留言内容，其中，在确定是的情况下，上述第一终端向上述业务服务器传输上述留言内容。
优选地，通过上述业务服务器继续接收上述第一终端传输的留言内容之前，包括：通过上述第二终端向上述业务服务器发送通知消息，其中，上述通知消息中携带有用于提示上述第一终端是否进行留言的信息；根据上述提示信息确定上述第一终端是否继续传输上述留言内容，其中，在确定是的情况下，上述第一终端向上述业务服务器传输上述留言内容。
优选地，通过上述业务服务器继续接收上述第一终端传输的留言内容，包括：通过上述业务服务器保存接收的上述留言内容；在确定上述第一终端传输结束时，将接收的上述留言内容封装成指定格式的信息；将封装得到的上述信息发送给上述第一终端。
优选地，将接收的上述留言内容封装成指定格式的信息，包括：将接收的上述留言内容保存为文件并生成统一资源定位符URL的链接信息，其中，上述链接信息为需要向上述第二终端发送的信息。
优选地，通过上述业务服务器保存接收的上述留言内容，包括：通过上述业务服务器保存上述第二终端在发送最后1个保活报文后接收的所有上述留言内容，其中，上述保活报文是指上述第二终端在媒体传输过程中每隔预定时间段向业务服务器发送的业务信令，该业务信令用于通知上述业务服务器上述第二终端处于在线状态。
根据本发明的另一个实施例，提供了一种基于互联网协议IP电话的留言业务处理装置，包括：监测模块，设置为监测第一终端和第二终端在呼叫过程中的媒体传输状态；接收模块，设置为在监测到上述第二终端与业务服务器的媒体传输状态中断时，通过上述业务服务器继续接收上述第一终端传输的留言内容；第一发送模块，设置为通过上述业务服务器将接收的上述留言内容发送给上述第二终端。
优选地，上述装置包括：第二发送模块，设置为通过上述业务服务器向上述第一终端发送通知消息，其中，上述通知消息中携带有用于提示上述第一终端是否进行留言的信息；第一确定模块，设置为根据上述提示信息确定上述第一终端是否继续传输上述留言内容，其中，在确定是的情况下，上述第一终端向上述业务服务器传输上述留言内容。
优选地，上述装置包括：第三发送模块，设置为通过上述第二终端向上述业务服务器发送通知消息，其中，上述通知消息中携带有用于提示上述第一终端是否进行留言的信息；第二确定模块，设置为根据上述提示信息确定上述第一终端是否继续传输上述留言内容，其中，在确定是的情况下，上述第一终端向上述业务服务器传输上述留言内容。
优选地，上述接收模块，包括：保存单元，设置为通过上述业务服务器保存接收的上述留言内容；封装单元，设置为在确定上述第一终端传输结束时，将接收的上述留言内容封装成指定格式的信息；发送单元，设置为将封装得到的上述信息发送给上述第一终端。
通过本发明，采用在监测到第二终端的媒体传输状态中断时，通过业务服务器继续接收第一终端传输的留言内容，进而通过业务服务器将留言内容发送给第二终端的技术问题，解决了相关技术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言内容等问题，能够有效提高应用可靠性，同时提高系统资源利用率。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1为根据本发明实施例的基于IP电话的留言业务处理方法的流程图；
图2为根据本发明实施例的基于IP电话的留言业务处理装置的结构框图；
图3为根据本发明实施例的基于IP电话的留言业务处理装置的另一结构框图；
图4为根据本发明优选实施例的终端间呼叫建立的流程示意图；
图5为根据本发明优选实施例的基于IP电话的留言业务处理方法的流程示意图；
图6为根据本发明优选实施例的基于IP电话的留言业务处理方法的另一流程示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
以下实施例可以应用到计算机中，例如应用到PC中。也可以应用到目前采用了智能操作系统中的移动终端中，并且并不限于此。对于计算机或移动终端的操作系统并没有特殊要求。例如，以下实施例可以应用到Windows操作系统中。
图1为根据本发明实施例的基于IP电话的留言业务处理方法的流程图。如图1所示，该方法包括以下处理步骤：
步骤S102，监测第一终端和第二终端在呼叫过程中的媒体传输状态；
步骤S104，在监测到第二终端与业务服务器的媒体传输状态中断时，通过业务服务器继续接收第一终端传输的留言内容；其中，该留言内容可以包括但不限于：文字、语言、视频、图像；
在本实施例中，在通过业务服务器继续接收上述第一终端传输的留言内容之前，需要取得第一终端的授权以使得第一终端继续向第二终端发送留言内容，具体可以通过以下两种实现方式：
第一种实现方式
通过业务服务器向第一终端发送通知消息，其中，上述通知消息中携带有用于提示第一终端是否进行留言的信息；根据上述提示信息确定第一终端是否继续传输上述留言内容，其中，在确定是的情况下，第一终端向业务服务器传输上述留言内容。
事实上，该种实现方式可以对应于但不限于以下场景：因为网络环境的原因，第二终端失去了网络连接。
第二种实现方式
通过第二终端向业务服务器发送通知消息，其中，上述通知消息中携带有用于提示第一终端是否进行留言的信息；根据上述提示信息确定第一终端是否继续传输上述留言内容，其中，在确定是的情况下，第一终端向业务服务器传输上述留言内容。
事实上，该种实现方式可以对应于但不限于以下场景：第二终端主动结束通话，并且，第二终端又希望收到第一终端后续传输的留言内容。
步骤S106，通过业务服务器将接收的上述留言内容发送给第二终端。
步骤S106可以通过以下处理过程实现：通过上述业务服务器保存接收的上述留言内容；在确定上述第一终端传输结束时，将接收的上述留言内容封装成指定格式的信息；将封装得到的上述信息发送给上述第一终端。具体地，可以将接收的上述留言内容保存为文件并生成统一资源定位符URL的链接信息，上述链接信息为需要向上述第二终端发送的信息。
在本实施例中，通过上述业务服务器保存接收的上述留言内容可以包括但不限于以下处理过程：通过上述业务服务器保存在第二终端发送最后1个保活报文后接收的所有上述留言内容，其中，上述保活报文是指第二终端在媒体传输状态中断每隔预定时间段向业务服务器发送的业务信令，该业务信令用于通知业务服务器第二终端处于在线状态。
在本实施例中还提供了一种基于IP电话的留言业务处理装置，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述，下面对该装置中涉及到的模块进行说明。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图2为根据本发明实施例的基于IP电话的留言业务处理装置的结构框图。如图2所示，该装置包括：
监测模块20，设置为监测第一终端和第二终端在呼叫过程中的媒体传输状态；
接收模块22，连接至监测模块20，设置为在监测到第二终端与业务服务器的媒体传输状态中断时，通过业务服务器继续接收第一终端传输的留言内容；
第一发送模块24，连接至接收模块，设置为通过业务服务器将接收的上述留言内容发送给第二终端。
可选地，在本实施例中，如图3所示，上述装置还可以包括以下处理模块：
第二发送模块26，设置为通过业务服务器向第一终端发送通知消息，其中，上述通知消息中携带有用于提示第一终端是否进行留言的信息；第一确定模块28，连接至第二发送模块26，设置为根据上述提示信息确定第一终端是否继续传输上述留言内容，其中，在确定是的情况下，第一终端向业务服务器传输上述留言内容。
可选地，如图3所示，上述装置还可以包括：第三发送模块30，设置为通过第二终端向业务服务器发送通知消息，其中，上述通知消息中携带有用于提示第一终端是否进行留言的信息；第二确定模块32，连接至第三发送模块30，设置为根据上述提示信息确定第一终端是否继续传输上述留言内容，其中，在确定是的情况下，第一终端向业务服务器传输上述留言内容。
在本实施例的一个优选实施方式中，如图3所示，接收模块22，包括：保存单元220，设置为通过业务服务器保存接收的上述留言内容；封装单元222，连接至保存单元220，设置为在确定第一终端传输结束时，将接收的上述留言内容封装成指定格式的信息；发送单元224，连接至封装单元222，设置为将封装得到的上述信息发送给第一终端。
需要说明的是，上述各个模块是可以通过硬件来实现的。例如：一种处理器，包括上述各个模块，或者，上述各个模块分别位于一个处理器中，也可以两个或多个模块位于同一处理器中。
为了更好地理解上述实施例，以下结合一个优选实施例详细说明。
首先，说明一下本实施例涉及的呼叫建立流程：
本实施例涉及到的IP通话信令可以采用任和一种现有的实现技术，在具体实施过程中，以SIP以及会话描述协议(Session Description Protocol，简称为SDP)作为会话交互以及媒体协商使用到的协议，本实施例涉及到的实时媒体传输技术可以采用任何一种现有的实现技术，在具体实施过程中采用的是实时传输协议(Real-time Transport Protocol，简称为RTP)。本文设计到的文件下载技术可以采用任何一种现有的实现技术，在具体实施过程中采用的超文本传输协议(Hypertext Transfer Protocol，简称为HTTP)。本实施例的呼叫建立流程如图4所示：
本实施例采用SIP协议进行呼叫信令的建议，步骤S402～S412完成呼叫建立流程，依据SIP协议发送请求和响应建立终端A、B以及业务服务器之间的呼叫关系。步骤S402～S412的关键点在于终端A在步骤S402中的携带的报文如表1所示：
表1
Figure PCTCN2014088675-appb-000001
服务器收到A的呼叫请求报文后通过步骤S404转发给终端B。终端B通过步骤S406发送如表2所示的应答报文给A。
表2
Figure PCTCN2014088675-appb-000002
服务器通过步骤S402～S406记录下了终端A和终端B各自需要的会话保活时间。
服务器通过步骤S408将B的应答转发给A，A通过步骤S410发送如下的应答响应给服务器。
表3
Figure PCTCN2014088675-appb-000003
服务器将此应答响应通过步骤S412转发给终端B。
至此，终端A和终端B通过服务器建立起了IP媒体通话。开始进行步骤S414的双向媒体传输。
当呼叫刚建立后，业务服务器通过S416A和S416B开始分别保存A和B发送的媒体流。
当呼叫建立后30秒开始的时候，A和B分别通过步骤S418A和S418B向服务器发送会话保活请求报文，当服务器收到A和B的保活请求报文后，开始通过步骤S420A和步骤S420B覆盖保存之前A和B发送的媒体流，即正常情况下，服务器分别保存A和B各30秒左右的媒体内容。
下面说明基于IP电话动态留言业务的方案。该方案包括了涉及通话和留言业务的终端和业务服务器。主要内容是：当终端A和B进行基于IP的语音或视频通话以及基于IP的视频共享的过程中(A和B已经完成呼叫建立的流程并且已经开始媒体数据的传输了)，通信的一方(假设B)发生了中断媒体传输的情况，这种情况分为以下两种场景：
场景1：因为网络环境的原因，B失去了网络连接。业务服务器监测到B失去了网络连接后，发送结束通话的信令给A，该信令中包含了提示A是否继续进行留言的信息。A收到该信令后决定是否进行留言，如果A决定进行留言，那么A继续传输媒 体，业务服务器保存A发送的媒体，当A结束发送媒体后(发送结束通话的信令到业务服务器)，业务服务器将A给B的留言保存成文件并生成一个URL的链接信息通过短信和电子邮件发送给B，由B根据URL下载业务服务器上A的留言。
场景2：B因为私人原因主动结束了通话，但是B又希望能收到A后续传输的媒体。于是B发送结束通话的信令给服务器，该信令中包含了提示A是否继续进行留言的信息。服务器在收到该信令后，发现了该信令中包含了B希望留言的信息，那么服务器在转发该信令的同时保存A发送的媒体。当A收到该信令后的流程和场景1相同。
在以下处理过程中，为了保证服务器能够完整保存B掉线后A传输的所有媒体内容，业务服务器会保存A和B在会话保活时长内的所有媒体数据。会话保活是指，A和B的通话关心建立好之后，A和B分别会定时向业务服务器发送一条业务信令，该信令被称之为会话保活信令，其目的是告诉服务器自己仍然在线。例如，如果A和B的保活时长是1分钟(即A和B每隔一分钟都会向服务器发送一条业务信令(保活信令))，业务服务器会实时的刷新保存A和B在1分钟内(保活时长)的媒体数据，即每个一分钟，业务服务器都会用最新保存的1分钟的媒体内容替换掉其前一分钟保存的内容。这样做的目的是，如果B在发送保活报文后30s内掉线了，由于服务器保存了B在发送上一次保活报文后一分钟内A发送的数据，这样A在这30s内的传输内容就不会丢失，保证了A在B掉线1分钟内上传的数据是完整的。后续业务服务器将一直保存B掉线后A发送的所有媒体数据，及业务服务器保存的A的媒体数据的时长是：60s(B发送最后一个保活报文后开始计时)+Ns(B掉线1分钟后)。
以下详细说明场景1的实施步骤。
用户场景1：终端B由于某种原因失去了网络连接，A继续传输媒体流到服务器，服务器将A传输的媒体保存成文件并生成URL通过短信和电子邮件的方式发送给B，该场景实施流程如图5所示：
说明如下：
业务服务器在60s内没有收到B的保活报文，业务服务器通过步骤S502发送结束呼叫请求给终端A，报文如表4所示：
表4
Figure PCTCN2014088675-appb-000004
业务服务器发送的呼叫结束报文其中携带Alert-Info字段，内容为“leaving Message”，终端A收到该请求后，解析出Alert-Info字段，提示用户是否继续发送媒体，如果用户选择同意，那么A通过步骤S502发送结束呼叫请求响应，报文如表5所示：
表5
Figure PCTCN2014088675-appb-000005
由于A的响应中携带了Alert-Info并且内容为“leaving Message”,因此业务服务器并结束接收A传输的媒体流，而是继续保存A的媒体流，并进入对终端A的“留言模式”。
在完成上述步骤后，终端A通过步骤S506向业务服务器执行单向媒体传输，业务服务器继而通过步骤S508保存终端A所发送的媒体。
终端A继续通过步骤S510发送保活报文维持本次的呼叫，由于业务服务器进入了对终端A的留言模式，因此业务服务器在收到A的保活报文后不再覆盖更新A的媒体流保存。
当终端A需要结束留言的时候通过步骤S514发送结束呼叫的请求，该请求不再携带Alert-Info字段。业务服务器收到后通过S516发送结束呼叫请求的响应，该响应也不携带Alert-Info字段。
业务服务器通过步骤S518生成一个URL链接，该链接是A针对B的留言的下载地址。
A通过步骤S520发送短信和电子邮件给B，短信和电子邮件的内容包含该URL的连接。
B收到短信或邮件后，可以通过该URL链接下载A的留言。
以下详细说明场景2的实施步骤。
用户场景2：终端B在和A的IP通话过程中因为某种原因需要结束通话，但又希望能收到A后续传输的通话内容，该场景实施流程如图6所示：
用户B通过步骤S602发送结束呼叫请求，该请求的报文内容如表6所示：
表6
Figure PCTCN2014088675-appb-000006
服务器收到该请求后立即通过步骤S604发送对该请求的响应给终端B，响应不携带Alert-Info。终端B正常结束会话。业务服务器针对终端A开始和场景1相同的业务流程实施。此处不再赘述。
现有的通话留言的方案都是基于用户无法建立呼叫的基础上实施的，而上述实施例的重点在“动态”二字上。上述实施例可以通过服务器和客户端的信令交互可以动态检测到用户在通话过程中需要进行留言的需求从而进行留言业务的实施。
此外上述实施例中，和客户端进行通话本地保存也是有区别和优势的。
通话内容本地保存占用用户客户端的空间，特别是视频内容，后续如果需要发送本地通话内容文件还需要消耗用户的网络流量。本业务中所有的通话留言内容都是保存在服务器上，并且可以进行业务流量包月的方式一方面吸引用户另一方面也不消耗用户网络流量；当用户发现对端掉线了再去进行通话内容本地保存时，或许已经有一些重要的内容已经错过了，本发明通过服务器自动保存通话双方在有效会话保活时长内的内容避免出现以上的问题。
综上所述，本发明实施例实现了以下有益效果：
用户在进行IP通话业务(无论是语音、视频通话或是视频共享业务)的时候，当通话中某一用户网络不可用的时候，不会再错过重要的实时性的信息。因此本发明实施例有效的保障了IP通话业务信息的完整性；目前大多数运营商都部署了基于IMS的IP通话业务，特别是一些运营商已经开始运营了基于IMS的VoLTE的4G网络通话业务。本发明实施例可以给运营商提供一种保持通话连续性的方案，作为一种IP通话业务的增强型功能，提升运营商的IP通话业务的竞争力。
在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式中描述的技术方案。
在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于：光盘、软盘、硬盘、可擦写存储器等。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所 组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
工业实用性
基于本发明实施例提供的上述技术方案，采用在监测到第二终端的媒体传输状态中断时，通过业务服务器继续接收第一终端传输的留言内容，进而通过业务服务器将留言内容发送给第二终端的技术问题，解决了相关技术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言内容等问题，能够有效提高应用可靠性，同时提高系统资源利用率。

Claims (10)

  1. 一种基于互联网协议IP电话的留言业务处理方法，包括：
    监测第一终端和第二终端在呼叫过程中的媒体传输状态；
    在监测到所述第二终端与业务服务器的媒体传输状态中断时，通过所述业务服务器继续接收所述第一终端传输的留言内容；
    通过所述业务服务器将接收的所述留言内容发送给所述第二终端。
  2. 根据权利要求1所述的方法，其中，通过所述业务服务器继续接收所述第一终端传输的留言内容之前，包括：
    通过所述业务服务器向所述第一终端发送通知消息，其中，所述通知消息中携带有用于提示所述第一终端是否进行留言的指示信息；
    根据所述指示信息确定所述第一终端是否继续传输所述留言内容，其中，在确定是的情况下，所述第一终端向所述业务服务器传输所述留言内容。
  3. 根据权利要求1所述的方法，其中，通过所述业务服务器继续接收所述第一终端传输的留言内容之前，包括：
    通过所述第二终端向所述业务服务器发送通知消息，其中，所述通知消息中携带有用于提示所述第一终端是否进行留言的提示信息；
    根据所述指示信息确定所述第一终端是否继续传输所述留言内容，其中，在确定是的情况下，所述第一终端向所述业务服务器传输所述留言内容。
  4. 根据权利要求1所述的方法，其中，通过所述业务服务器继续接收所述第一终端传输的留言内容，包括：
    通过所述业务服务器保存接收的所述留言内容；
    在确定所述第一终端传输结束时，将接收的所述留言内容封装成指定格式的信息；
    将封装得到的所述信息发送给所述第一终端。
  5. 根据权利要求4所述的方法，其中，将接收的所述留言内容封装成指定格式的信息，包括：
    将接收的所述留言内容保存为文件并生成统一资源定位符URL的链接信息，其中，所述链接信息为需要向所述第二终端发送的信息。
  6. 根据权利要求4所述的方法，其中，通过所述业务服务器保存接收的所述留言内容，包括：
    通过所述业务服务器保存所述第二终端在发送最后1个保活报文后接收的所有所述留言内容，其中，所述保活报文是指所述第二终端在媒体传输过程中每隔预定时间段向业务服务器发送的业务信令，该业务信令用于通知所述业务服务器所述第二终端处于在线状态。
  7. 一种基于互联网协议IP电话的留言业务处理装置，包括：
    监测模块，设置为监测第一终端和第二终端在呼叫过程中的媒体传输状态；
    接收模块，设置为在监测到所述第二终端与业务服务器的媒体传输状态中断时，通过所述业务服务器继续接收所述第一终端传输的留言内容；
    第一发送模块，设置为通过所述业务服务器将接收的所述留言内容发送给所述第二终端。
  8. 根据权利要求7所述的装置，其中，包括：
    第二发送模块，设置为通过所述业务服务器向所述第一终端发送通知消息，其中，所述通知消息中携带有用于提示所述第一终端是否进行留言的指示信息；
    第一确定模块，设置为根据所述提示信息确定所述第一终端是否继续传输所述留言内容，其中，在确定是的情况下，所述第一终端向所述业务服务器传输所述留言内容。
  9. 根据权利要求7所述的装置，其中，包括：
    第三发送模块，设置为通过所述第二终端向所述业务服务器发送通知消息，其中，所述通知消息中携带有用于提示所述第一终端是否进行留言的指示信息；
    第二确定模块，设置为根据所述指示信息确定所述第一终端是否继续传输所述留言内容，其中，在确定是的情况下，所述第一终端向所述业务服务器传输所述留言内容。
  10. 根据权利要求7所述的装置，其中，所述接收模块，包括：
    保存单元，设置为通过所述业务服务器保存接收的所述留言内容；
    封装单元，设置为在确定所述第一终端传输结束时，将接收的所述留言内容封装成指定格式的信息；
    发送单元，设置为将封装得到的所述信息发送给所述第一终端。
PCT/CN2014/088675 2013-10-23 2014-10-15 基于ip电话的留言业务处理方法及装置 WO2015058648A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310504576 2013-10-23
CN201310504576.7 2013-10-23

Publications (1)

Publication Number Publication Date
WO2015058648A1 true WO2015058648A1 (zh) 2015-04-30

Family

ID=52992256

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/088675 WO2015058648A1 (zh) 2013-10-23 2014-10-15 基于ip电话的留言业务处理方法及装置

Country Status (2)

Country Link
CN (1) CN104796564B (zh)
WO (1) WO2015058648A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110647416A (zh) * 2019-08-30 2020-01-03 福建天泉教育科技有限公司 一种消息队列跟踪记录方法及系统

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791538B (zh) * 2016-02-17 2020-06-26 钉钉控股（开曼）有限公司 提示方法及装置
CN112565661A (zh) * 2019-09-10 2021-03-26 中兴通讯股份有限公司 一种视频会议通信方法、装置以及计算机可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101170611A (zh) * 2007-11-16 2008-04-30 中兴通讯股份有限公司 实现音视频信箱服务的方法及系统
US20080186929A1 (en) * 2006-12-21 2008-08-07 Rice Robert M Systems, methods, and apparatus for communicating the state of a wireless user device in a wireless domain to an application server in an internet protocol (ip) domain
CN101800950A (zh) * 2009-12-29 2010-08-11 宇龙计算机通信科技(深圳)有限公司 一种通话过程中实现语音留言的方法、系统及移动终端
CN101822035A (zh) * 2007-12-27 2010-09-01 株式会社Ntt都科摩 服务器装置及消息发送方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100686382B1 (ko) * 2005-07-08 2007-02-22 엔에이치엔(주) 싱크 서버를 이용한 메신저 알림 시스템 및 방법
US8131268B2 (en) * 2008-08-05 2012-03-06 International Business Machines Corporation Managing wireless transmissions upon unintentional disconnection of service
CN102572728B (zh) * 2010-12-15 2015-09-16 中兴通讯股份有限公司 一种传输留言信息的方法及装置和系统
CN102223399B (zh) * 2011-05-31 2013-08-14 中国联合网络通信集团有限公司 基于智能终端的联系人会话展现方法及系统
CN103095938B (zh) * 2011-10-31 2017-09-29 中兴通讯股份有限公司 语音留言方法以及语音信箱系统
US9014350B2 (en) * 2012-03-13 2015-04-21 Semotus Inc. Method for providing a beacon to ensure delivery of automated messages over a telephone or voice messaging system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080186929A1 (en) * 2006-12-21 2008-08-07 Rice Robert M Systems, methods, and apparatus for communicating the state of a wireless user device in a wireless domain to an application server in an internet protocol (ip) domain
CN101170611A (zh) * 2007-11-16 2008-04-30 中兴通讯股份有限公司 实现音视频信箱服务的方法及系统
CN101822035A (zh) * 2007-12-27 2010-09-01 株式会社Ntt都科摩 服务器装置及消息发送方法
CN101800950A (zh) * 2009-12-29 2010-08-11 宇龙计算机通信科技(深圳)有限公司 一种通话过程中实现语音留言的方法、系统及移动终端

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110647416A (zh) * 2019-08-30 2020-01-03 福建天泉教育科技有限公司 一种消息队列跟踪记录方法及系统
CN110647416B (zh) * 2019-08-30 2023-03-24 福建天泉教育科技有限公司 一种消息队列跟踪记录方法及系统

Also Published As

Publication number Publication date
CN104796564B (zh) 2019-02-26
CN104796564A (zh) 2015-07-22

Similar Documents

Publication Publication Date Title
US11621911B2 (en) System and method for client communication in a distributed telephony network
US11165853B2 (en) System and method for managing media in a distributed communication network
US9350642B2 (en) System and method for managing latency in a distributed telephony network
EP2227890B1 (en) Methods for facilitating communication between Internet Protocol Multimedia Subsystem (IMS) devices and non-IMS devices
US20070223462A1 (en) Enhanced service delivery platform that provides a common framework for use by IMS and Web applications in delivering services
US20150358795A1 (en) Browser emergency call method, system, and mobile device in real-time communication
EP2584760B1 (en) Method for realizing video browsing, ip multimedia subsystem (ims) video monitoring system, and monitoring front end
CN111479121A (zh) 一种基于流媒体服务器的直播方法及系统
WO2007068209A1 (fr) Procede, systeme et dispositif d'envoi de messages instantanes ims
WO2015058648A1 (zh) 基于ip电话的留言业务处理方法及装置
JP2008153782A (ja) 呼管理方法、呼管理システム、およびメッセージ処理サーバシステム
US20130142085A1 (en) Call transfer processing in sip mode
JP4723676B2 (ja) セッション状態の通知に係る通信方法、サーバ、およびプログラム
EP2200254B1 (en) Mobile network system and guidance message providing method
WO2017000481A1 (zh) 语音通话的拨号方法和装置
US11540209B2 (en) Method for determining a set of encoding formats in order to establish a communication
KR102396634B1 (ko) 무선 통신 시스템에서 메시지 수신 정보를 송신하기 위한 장치 및 방법
CN102548025B (zh) 一种降低移动VoIP呼叫建立时延方法
WO2012052705A1 (en) Data communication
CN116155868A (zh) 电信通讯方法、电子设备及存储介质
FR2860936A1 (fr) Procede et systeme de controle de communication multi-terminaux
US20140355486A1 (en) Method and apparatus for call handling signaling
Popovici et al. SIP-based application level mobility for reconfigurable hybrid wireless systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14855532

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14855532

Country of ref document: EP

Kind code of ref document: A1