WO2009082945A1 - Procédé, système et appareil de communication multiterminal - Google Patents

Procédé, système et appareil de communication multiterminal Download PDF

Info

Publication number
WO2009082945A1
WO2009082945A1 PCT/CN2008/073608 CN2008073608W WO2009082945A1 WO 2009082945 A1 WO2009082945 A1 WO 2009082945A1 CN 2008073608 W CN2008073608 W CN 2008073608W WO 2009082945 A1 WO2009082945 A1 WO 2009082945A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
terminal
called party
voice
session
Prior art date
Application number
PCT/CN2008/073608
Other languages
English (en)
French (fr)
Inventor
Lizhe Yao
Chuansuo Ding
Jie Zhang
Shiqian Yang
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP08865936A priority Critical patent/EP2107852A4/en
Priority to US12/481,327 priority patent/US20090244255A1/en
Publication of WO2009082945A1 publication Critical patent/WO2009082945A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1089—In-session procedures by adding media; by removing media
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H04L65/4015—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference where at least one of the additional parallel sessions is real time or time sensitive, e.g. white board sharing, collaboration or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • Multi-terminal communication method, system and device The present application claims to be submitted to the Chinese Patent Office on December 25, 2007, application number 200710301347.X, and the invention name is "a multi-terminal communication method, system and device" Chinese patent Priority of the application, the entire contents of which are incorporated herein by reference.
  • Embodiments of the present invention relate to the field of mobile communications technologies, and in particular, to a multi-terminal communication method, system, and apparatus. Background technique
  • IPTV Internet Protocol Television
  • IP broadcast television service uses a television or a personal computer as a display terminal to provide users with broadband services such as digital broadcast television, video services, information services, interactive communities, interactive leisure entertainment, and e-commerce through broadband networks.
  • broadband services such as digital broadcast television, video services, information services, interactive communities, interactive leisure entertainment, and e-commerce through broadband networks.
  • the main features of IPTV are interactivity and real-time. Its system structure mainly includes subsystems such as streaming media service, program editing, storage and authentication and billing.
  • the main storage and transmission content is streaming media files, based on IP network transmission.
  • a local server is set at the edge of the network.
  • the user terminal can be an IP set top box (Set Top Box, hereinafter referred to as STB) + a television set, or a PC.
  • STB IP set Top Box
  • IPTV convergence service such as the user binding a fixed telephone, mobile phone or PHS to the IPTV service, when other users with video communication capabilities want to make a video call with the user, and the fixed telephone of the user's home or the If the user's mobile phone does not have video capability, the user can display the video portion of the incoming call through IPTV.
  • a session exchange center server Session Transfer
  • STS Session Transfer Server
  • STS session exchange center server
  • proxying multiple terminals to communicate with the peer for voice and video data sent by the peer, the STS is first received through the STS, and then the STS decodes the voice and video data and sends them separately.
  • the STS For multiple terminals; the same is required for the STS to combine the data sent by multiple terminals and then send them to the peer end. Therefore, this will impose a heavy burden on the local server to which the STS belongs, consuming a large amount of resources of the local server, thereby affecting the system. Performance. Summary of the invention
  • the problem to be solved by the embodiments of the present invention is to provide a multi-terminal communication method, system, and device.
  • multiple terminals of the STS agent on the local server must be used to communicate with the peer end, so that the local server is brought to the local server.
  • a heavy burden a technical flaw that consumes a lot of resources on the local server.
  • an embodiment of the present invention provides a multi-terminal communication method, which includes:
  • the embodiment of the present invention further provides a multi-terminal communication system, including a calling party and a service proxy server.
  • the calling party is configured to initiate a call request to the voice terminal of the called party by using the service proxy server, where the call request includes a video media identifier;
  • the service proxy server is configured to establish a voice session between the voice terminal of the called party and the calling party, and establish a video session between the video terminal of the called party and the calling party according to the video media identifier .
  • the embodiment of the present invention further provides a service proxy server, including a request message receiving module, a voice session creating module, and a video session creating module, where the request message receiving module is used.
  • a service proxy server including a request message receiving module, a voice session creating module, and a video session creating module, where the request message receiving module is used.
  • the voice session creating module is configured to create a voice session between the voice terminal of the called party and the calling party;
  • the video session creating module is configured to establish a video session of the called party's video terminal and the calling party according to the video media identifier received by the request message receiving module.
  • the technical solution of the embodiment of the present invention has the following advantages, because the voice session of the calling party and the called party's voice terminal, the video session of the calling party and the called party's video terminal are respectively established by the service proxy server, thereby making the calling party
  • the data transmitted between the party and the called party (multiple terminals) no longer needs to pass through the local server, thereby alleviating the burden on the local server, and by the embodiment of the present invention, only the service proxy server and the calling party and the called party need to be added. The signaling interaction between them is sufficient, and therefore does not burden the service proxy server.
  • FIG. 1 is a flowchart of a first embodiment of a multi-terminal communication method according to the present invention
  • FIG. 2 is a signaling flowchart of a UE registration in a second embodiment of the multi-terminal communication method of the present invention
  • FIG. 3 is a schematic diagram of a method for the multi-terminal communication method of the present invention, in which the video terminal STB of the called party applies for subscription to the SBF Signaling flow chart of the fixed voice terminal of the party;
  • FIG. 4 is a signaling flowchart of a IPTV-based multi-terminal communication method in a second embodiment of the multi-terminal communication method of the present invention
  • FIG. 5 is a signaling flowchart of a IPTV-based multi-terminal communication method in a third embodiment of the multi-terminal communication method of the present invention.
  • FIG. 6 is a schematic structural diagram of an embodiment of a multi-terminal communication system according to the present invention. detailed description
  • FIG. 1 is a flowchart of a first embodiment of a multi-terminal communication method according to the present invention. As shown in FIG. 1, the method in this embodiment includes:
  • Step 101 Receive a call request initiated by a calling terminal to a voice terminal of the called party, where the call request includes a video media identifier.
  • Step 102 Establish a voice session between the voice terminal of the called party and the calling party, and establish a video session between the video terminal of the called party and the calling party according to the video media identifier.
  • the first embodiment of the multi-terminal communication method of the present invention mainly consists of establishing a session between the calling party and the called party by using a Service Broker Function (SBF), respectively, assuming that the called party includes the STB and the
  • SBF Service Broker Function
  • the mobile terminal can establish a STB and caller video session through the SBF, and establish a voice session between the mobile terminal and the calling party, so that the data transmitted between the calling party and the called party (multiple terminals) does not need to pass through the local
  • the server thereby alleviating the burden on the local server, and the first embodiment of the multi-terminal communication method of the present invention only needs to increase the signaling interaction between the SBF and the calling party and the called party, and thus does not bring the SBF burden.
  • the second embodiment of the multi-terminal communication method of the present invention proposes an application scenario in real life, in which the called party has many
  • the terminal is specifically a fixed telephone of the STB and the user, but it should be noted that the following application scenario is only a good understanding of the technical solution proposed by the first embodiment of the multi-terminal communication method of the present invention, but does not mean that the present invention
  • the first embodiment of the inventive multi-terminal communication method can only be applied to such a scenario.
  • the STB of the user A's home is bound to the fixed telephone, and the call state of the fixed telephone is subscribed to on the STB, and the fixed telephone of the user A's home does not have the capability of displaying the video.
  • User B initiates a video call request to the fixed telephone of User A's home, User A Answering the call, while the user B's video is displayed on the TV, asking whether to receive, user A chooses to receive, and then user A talks to user B through the fixed telephone while watching the video from user B through the television.
  • user B initiates a video call request to user A's home fixed telephone, user A's home TV does not turn on, user A first answers the call, user B tells user A that he can also send his own video, and user A can open TV, at this time, a pop-up window on the screen asks whether to receive the video of User B, User A selects to receive, and then User A talks to User B through the fixed telephone while watching the video from User B through the TV.
  • IPTV SCF IPTV Service Control Function
  • SBF SBF
  • IPTV Media Function includes both Media Control and Media Delivery for media control and transmission.
  • the user terminal (User Terminal, hereinafter referred to as UE) is first successfully registered on the SBF and the General Telecommunication Application Server (GTAS).
  • GTAS is equivalent to the call control/processing server in the telephone system and is responsible for controlling the signaling between the calling party and the called party, such as ringing, off-hook, and on-hook.
  • the second embodiment of the multi-terminal communication method of the present invention proposes the following UE registration procedure.
  • FIG. 2 is a signaling flowchart of UE registration in the second embodiment of the multi-terminal communication method of the present invention. As shown in FIG. 2, the process may include the following steps:
  • Step S401 The UE sends a registration message to the IMS core layer.
  • Step S402 the IMS core layer returns a SIP 401 message to the UE, and the server returns to the client, indicating that the client is not authorized.
  • the UE sends the request for the first time such as If the message returns to the SIP 401, the UE is not authorized.
  • the UE needs to send a registration request again which needs to carry its own authentication information, such as a user name and a password.
  • the reason why the registration message is sent twice is the SIP protocol. Regulation).
  • Step S403 The UE sends a registration message to the IMS core layer.
  • Step S404 the IMS core returns a 200 OK: to the UE.
  • Step S405 Initiating a third party registration according to an Initial Filter Criteria (hereinafter referred to as IFC).
  • IFC is part of the user subscription data stored in the Home Subscriber Server (HSS).
  • HSS Home Subscriber Server
  • S service call session control function
  • IFC defines the conditions and destinations of the service trigger (Application Server, hereinafter referred to as AS) according to different priorities.
  • AS Application Server
  • the S-CSCF performs IFC match detection when processing user service requests, and the specified trigger condition is met.
  • the AS triggers, so that the AS can control the secondary service according to the established business logic in the AS.
  • the so-called third-party registration means that the S-CSCF automatically assists the user to initiate registration according to the user's IFC, that is, the user actually registers with the IMS core layer, but the IMS core layer finds that the user should also go to a server according to IFC. When you register, you will be automatically registered for the user.
  • Step S406 the IMS core layer proxy UE sends a registration request to the SBF.
  • Step S407 The SBF returns a 200 OK to the IMS core layer, indicating that the UE has successfully registered.
  • Step S409 the GTAS returns a 200 OK to the IMS core layer, indicating that the UE has successfully registered.
  • the called party's terminal including the STB and the telephone
  • the called party's video terminal STB and the called party's voice terminal (such as a fixed telephone, a PHS, a mobile phone, etc.) in the SBF
  • the video terminal STB that needs the called party can know the call state of the called party's voice terminal, and therefore the called party's video terminal STB needs to send a subscription request to the SBF, requesting the called party's video terminal SBF to receive To the called party bound to it
  • the corresponding call request can be notified to the video terminal of the called party
  • FIG. 3 is a signaling flowchart of a video terminal STB of a called party requesting subscription to a voice terminal bound to a called party in a second embodiment of the multi-terminal communication method according to the present invention. As shown in FIG. 3, in this embodiment, The called video terminal STB has been successfully registered on the IPTV SCF.
  • Step S501 The video terminal STB of the called party initiates a subscription request to the SBF by using a subscribe command, where the subscription request includes information of the voice terminal bound to the STB.
  • Step S502 the SBF check determines whether the voice terminal of the called party has a binding relationship with the video terminal STB of the called party according to the information of the voice terminal of the called party carried in the subscription request packet, if there is a binding relationship. Then, it is decided to accept the subscription request of the video terminal STB of the called party and perform step S503, otherwise reject the subscription request of the video terminal STB of the called party.
  • Step S503 The SBF returns a subscription success message to the video terminal STB of the called party by using the notify command. After the subscription of the video terminal STB of the called party is successful, if there is a call request from the called party whose calling direction is bound to the video terminal STB of the called party, the SBF also forwards the call request to the called party. Party video terminal STB.
  • FIG. 4 is a signaling flowchart of a IPTV-based multi-terminal communication method in a second embodiment of the multi-terminal communication method of the present invention.
  • the video terminal STB of the called party has succeeded on the SBF. Subscribe to the session state of the called party's voice terminal to which it is bound.
  • the called party includes at least one called party's voice terminal (such as a fixed telephone, PHS, mobile phone, etc.) and a called party's video. Terminal (such as STB). Includes the following steps:
  • Step S601 the calling direction SBF sends a call request INVITE message, where the session description protocol (SDP) in the INVITE message includes a video media identifier, which identifies the caller request to initiate Is an audio and video session.
  • the SDP1 information also includes capability information of the calling party, such as whether the calling party supports a video session or the like.
  • Step S602 After receiving the INVITE message of the calling party, the SBF determines whether the SDP1 information in the INVITE message includes a video media identifier. If the video media identifier is included, the SBF records the video session request. The SBF may also determine, according to the calling party capability information in the SDP1 information, whether the calling party can support the video session. If the calling party does not support the video session, the SDP1 information sent by the calling party includes the video. The media identity, SBF will also not establish a video session for the calling party.
  • SDP session description protocol
  • Step S603 The SBF forwards the INVITE message to the voice terminal of the called party.
  • Step S604 After the called party's voice terminal goes off-hook, it returns a response message 200 OK to the SBF.
  • the response message includes the SDP2 information of the voice terminal of the called party, and the SDP2 information also includes the capability information of the voice terminal.
  • Step S605 The SBF determines, according to the SDP2 information of the voice terminal of the called party in the response message, whether the voice terminal of the called party supports the video function. If the voice terminal of the called party does not support the video function, the SBF will be called by the called party.
  • the response message of the voice terminal is forwarded to the calling party, and after receiving the response message, the calling party establishes a voice session with the voice terminal of the called party.
  • Step S606 the SBF searches for the video terminal of the called party that has a binding relationship with the voice terminal of the called party according to the video session request recorded in step S602, and notifies the call request sent by the calling party's voice terminal according to the calling direction.
  • the video terminal of the called party initiates a video session request.
  • the notification (NOTIFY) message (for example: Notify ⁇ Request-URI: STB> Body: state is confirmed, call-id, fromtag, totag) notifies the called party's video terminal to initiate a video session request.
  • Step S607 after receiving the notification message of the SBF, the video terminal of the called party explicitly has a video session request to the user on the video terminal of the called party, and asks the user whether to agree to connect to the video of the calling party.
  • the timer is started, and after the timer expires, the user consent command is not received, and the video session request is rejected by default. If the user disagrees with the video session request, the join video session request is not sent to the SBF.
  • Step S608 if the user agrees to the video session request, the video terminal of the called party sends a video session join request to the SBF.
  • the video terminal wants to join an existing session, where the video session request INVITE message also carries the SDP information (SDP3) of the video terminal of the called party, and the SDP3 includes the video description information of the video terminal of the called party.
  • SDP3 SDP information
  • Step S609 after receiving the video session joining request from the video terminal of the called party, the SBF matches the Join header field in the video session joining request to the existing voice session of the calling party and the called party's voice terminal. And combining the video capability of the video terminal of the called party and the voice capability of the voice terminal, and then sending a REINVITE request to the calling party, and requesting the calling party to establish a video session, specifically: the video description information in the SDP3. Adding to SDP2 to generate a new SDP information SDP4, and sending it to the calling party through the REINVITE request, the REINVITE request carries SDP4, so that the calling party can establish a voice session until the peer that requests the video session is established. The called party.
  • Step S610 After receiving the REINVITE request, the calling party returns a 200 OK response message to the SBF, where the SDP information (SDP5) in the response message carries the video description information and the voice description information of the calling party.
  • SDP5 SDP information
  • Step S611 after receiving the response message returned by the calling party, the SBF removes the voice description information of the calling party in the SDP5 in the response message, leaving only the video description information of the calling party, and removing the voice description information.
  • the new SDP5 is returned to the called party's video terminal via the 200 OK. Because if the voice description information of the calling party is not removed, not only the video session of the calling party and the called party's video terminal but also the voice session of the calling party and the called party's video terminal will be established.
  • Step S612 after receiving the INVITE request of the SBF, the video terminal of the called party returns an ACK confirmation message to the SBF.
  • Step S613 the SBF forwards the ACK confirmation message of the called party's video terminal to the calling party, thereby establishing a video session between the calling party and the called party's video terminal.
  • the video session between the called party's video terminal and the calling party is re-established by the SBF in the above embodiment, so that the called party's voice terminal without video receiving capability can transfer the video session with the calling party to On the video terminal of the called party bound to the voice terminal of the called party, for the SBF, only the video session of the calling party and the called party needs to establish a corresponding video session, without the need for the agent as in the prior art.
  • a plurality of terminals of the called party perform a session with the calling party. Therefore, the method provided by the embodiment of the present invention can effectively solve the problem of communication between the multi-terminal and the calling party on the basis of not burdening the SBF.
  • FIG. 5 is a signaling flowchart of a IPTV-based multi-terminal communication method in a third embodiment of the multi-terminal communication method according to the present invention.
  • the called party's video when the calling party initiates a session request in this embodiment is shown in FIG.
  • the terminal is not online.
  • the SBF receives the caller's voice terminal from the called party to send a reminder to the called party to open the video terminal of the called party. After the called party's video terminal is turned on, the SBF is sent to the SBF.
  • the SBF Sending a request to subscribe to the call state of the called party's voice terminal, and after the subscription is successful, the SBF establishes a video session between the called party's video terminal and the calling party, thereby transferring the video session with the calling party to On the video terminal of the called party bound to the voice terminal of the called party.
  • Step S701 The calling direction SBF sends a call request INVITE message, where the SDP1 information in the INVITE message includes a video media identifier, and the calling party requests to initiate an audio and video session, not just an audio session.
  • the SDP1 information also includes capability information of the calling party, such as whether the calling party supports video sessions or the like.
  • Step S702 After receiving the INVITE message of the calling party, the SBF determines whether the SDP1 information in the INVITE message includes a video media identifier. If the video media identifier is included, the SBF records the video session request. The SBF may also determine, according to the calling party capability information in the SDP1 information, whether the calling party can support the video session, and if the calling party does not support the video session, even if the SDP1 information sent by the calling party includes Video media logo, SBF will also not establish a video session for the calling party.
  • Step S703 The SBF forwards the INVITE message to the voice terminal of the called party.
  • Step S704 after the called party's voice terminal goes off-hook, it returns a response message 200 OK to the SBF, where the response message includes SDP2 information of the called party's voice terminal, and the SDP2 information also includes the called party's voice terminal.
  • the response message includes SDP2 information of the called party's voice terminal, and the SDP2 information also includes the called party's voice terminal.
  • Ability information
  • Step S705 The SBF determines, according to the SDP2 information of the voice terminal of the called party in the response message, whether the voice terminal of the called party supports the video function. If the voice terminal of the called party does not support the video function, the SBF will be called by the called party.
  • the response message of the voice terminal is forwarded to the calling party, and after receiving the response message, the calling party establishes a voice session with the voice terminal of the called party.
  • Step S706 the SBF records the video session request according to step S602, and the SBF searches for the video terminal of the called party that has a binding relationship with the voice terminal of the called party, and determines whether the video terminal of the called party is powered on. In this embodiment, the video terminal is powered off, so the SBF prompts the called party user to open the video terminal through the voice terminal of the called party.
  • Step S707 After receiving the prompt message of the SBF, the called party user opens the video terminal of the called party if he is willing to receive the video request of the calling party. After the video terminal of the called party is turned on, it needs to register successfully on the IPTV SCF.
  • Step S708 After the registration, the video terminal of the called party sends a SUBSCRIBE request to the SBF to request to subscribe to the call state of the called party's voice terminal.
  • Step S709 the SBF receives the SUBSCRIBE request of the video terminal of the called party, and queries whether the video terminal of the called party and the called party's voice terminal of the called party have a binding state, and if there is a binding state, the SBF is allowed.
  • the calling party's video terminal subscribes to the calling state of the called party's voice terminal. And notifying the video terminal of the called party to initiate a video session request. Specifically, the video terminal of the called party is notified to initiate a video conference request by using a NOTIFY message (for example, Notify ⁇ Request-URI:STB> Body: state is confirmed, call-id, fromtag, totag).
  • a NOTIFY message for example, Notify ⁇ Request-URI:STB> Body: state is confirmed, call-id, fromtag, totag.
  • Step S710 after the video terminal of the called party receives the video session request of the SBF, The called party's video terminal explicitly has a video session request to the user, and asks the user whether to agree to the video connected to the calling party.
  • the timer is started. If the user does not receive the instruction of the user after the timer expires, the video session request is rejected by default. If the user does not agree to the video session request, the video session join request is not sent to the SBF.
  • the video terminal indicating that the called party wants to join an existing session, wherein the video session request INVITE message also carries the SDP information (SDP3) of the video terminal of the called party, where the SDP3 includes the video terminal of the called party.
  • Video description information SDP information
  • Step S712 after receiving the video session joining request from the video terminal of the called party, the SBF matches the Join header field in the video session joining request to the existing voice session of the calling party and the called party's voice terminal. And combining the video capability of the video terminal of the called party and the voice capability of the voice terminal, and then sending a REINVITE request to the calling party, and requesting the calling party to establish a video session, specifically: the video description information in the SDP3. Adding to SDP2 to generate a new SDP information SDP4, and sending it to the calling party through the REINVITE request, the REINVITE request carries SDP4, so that the calling party can establish a voice session until the peer that requests the video session is established. The called party.
  • Step S713 After receiving the REINVITE request, the calling party returns a response message of 200 OK to the SBF, where the SDP information (SDP5) in the response message carries the video description information and the voice description information of the calling party.
  • SDP information SDP5
  • Step S714 after receiving the response message returned by the calling party, the SBF removes the voice description information of the calling party in the SDP5 in the response message, leaving only the video description information of the calling party, and removing the voice description information. After the new SDP5 returns the video to the called party via 200 OK Terminal. Because if the voice description information of the calling party is not removed, not only the video session of the calling party and the called party's video terminal but also the voice session of the calling party and the called party's video terminal will be established.
  • Step S715 After receiving the INVITE request of the SBF, the video terminal of the called party returns an ACK confirmation message to the SBF.
  • Step S716 the SBF forwards the ACK confirmation message of the called party's video terminal to the calling party, thereby establishing a video session between the calling party and the called party's video terminal.
  • FIG. 6 is a schematic structural diagram of an embodiment of a multi-terminal communication system according to the present invention. As shown in FIG. 6, this embodiment is a schematic diagram of a structure based on IPTV, where the system includes calling party 1 and SBF 3, and calling party 1 is used to pass SBF. 3, a call request is initiated to the voice terminal 21 of the called party, where the call request includes a video media identifier; the SBF 3 is used to establish a voice session between the voice terminal 21 of the called party and the calling party 1 and notify the video media according to the identifier The video terminal 22 of the called party initiates a video session request to the calling party 1 to establish a video session between the video terminal 22 of the called party and the calling party 1.
  • the SBF 3 includes a request message receiving module 31, a voice session creating module 32, a notification module 33, and a video session creating module 34.
  • the request message receiving module 31 is configured to receive a call initiated by the calling party 1 to the called party's voice terminal 21.
  • the request, the call request includes a video media identifier;
  • the voice session creation module 32 is configured to create a voice session of the called party's voice terminal 21 and the calling party 1;
  • the notification module 33 is configured to use the video media identifier notification in the call request
  • the video terminal 22 of the called party initiates a video session request to the calling party 1;
  • the video session creating module 34 is configured to establish a video session between the video terminal 22 of the called party and the calling party 1.
  • the SBF 3 further includes a subscription request receiving module 35, a binding relationship query module 36, and a subscription message returning module 37.
  • the subscription request receiving module 35 is configured to receive a subscription request initiated by the video terminal 22 of the called party, where the subscription request is carried.
  • the video terminal 22 of the called party requests the subscription of the called party's voice terminal 21;
  • the binding relationship query module 36 is configured to detect the called party's voice terminal 21 and the called party according to the identity of the called party's voice terminal 21. Whether the called video terminal 22 has a binding relationship; the subscription message returning module 37 is configured to determine in the binding relationship query module 36. After the voice terminal 21 of the called party has a binding relationship with the video terminal 22 of the called party, the message of the subscription success is returned to the video terminal 22 of the called party.
  • the SBF 3 may further include a join request receiving module 38, a matching merge module 39 and a removal module 40, and the join request receiving module 38 is configured to receive a video session join request sent by the called party's video terminal 22, requesting to join the called party.
  • a voice session of the voice terminal 21 and the calling party 1 the video session joining request carries the video capability description information of the video terminal 22 of the called party;
  • the matching merge module 39 is configured to send the video of the called party according to the video session joining request
  • the terminal 22 matches the voice session of the calling party 1 and the called party's voice terminal 21, and combines the video capability description information of the called party's video terminal 22 with the voice capability description information of the called party's voice terminal 21,
  • the calling party 1 sends a re-request message; after the receiving module 40 receives the acknowledgment message of the calling party 1, the voice part of the acknowledgment message is removed, and a video session between the video terminal 22 of the called party and the calling party 1 is established.
  • the SBF 3 may further include a determining module 41 and an opening prompting module 42.
  • the determining module 41 is configured to receive, at the request message receiving module 31, a call request initiated by the calling party 1 to the called party's voice terminal 22, and the call is made. After the video media identifier is included in the request, it is determined whether the video terminal 22 of the called party bound to the called party's voice terminal 21 is online; the prompting module 42 is configured to determine, in the determining module 41, that the called party's video terminal 22 is not When going online, a message is sent to the called party's voice terminal 21 to prompt the user to turn on the called party's video terminal 22.
  • the voice session of the calling party and the called party's voice terminal, the video session of the calling party and the called party's video terminal are respectively established by the SBF, so that the calling party and the called party (multiple terminals) are enabled.
  • the data transmitted between the two does not need to pass through the local server, thereby alleviating the burden on the local server, and by this embodiment, it is only necessary to increase the signaling interaction between the SBF and the calling party and the called party, and therefore will not give SBF brings a burden.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

一种多终端通信方法、 ***和装置 本申请要求于 2007 年 12 月 25 日提交中国专利局、 申请号为 200710301347.X, 发明名称为"一种多终端通信方法、 ***和装置"的中国 专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明实施例涉及移动通信技术领域， 特别涉及一种多终端通信方 法、 ***和装置。 背景技术
网络电视（ Internet Protocol Television, 以下简称： IPTV )是指基于
IP协议的电视广播服务。 该业务将电视机或个人计算机作为显示终端， 通 过宽带网络向用户提供数字广播电视、 视频服务、 信息服务、 互动社区、 互动休闲娱乐、 电子商务等宽带业务。 IPTV 的主要特点是交互性和实时 性， 它的***结构主要包括流媒体服务、 节目釆编、 存储及认证计费等子 ***， 主要存储及传送的内容是流媒体文件， 基于 IP 网络传输， 通常要 在网络边缘设置本地服务器， 用户终端可以是 IP 机顶盒（Set Top Box, 以下简称： STB ) +电视机， 也可以是 PC。
随着 IPTV 业务的不断推广和迅速的普及， 将会出现越来越多基于
IPTV的融合业务， 如用户将家中固定电话、 手机或者小灵通等与 IPTV业 务绑定， 当其他具有视频通讯能力的用户希望与该用户进行视频通话的时 候， 且该用户家中的固定电话或者该用户的手机不具备视频能力， 则用户 可以将来电的视频部分通过 IPTV展现出来。
在实现本发明实施例过程中，发明人发现现有技术中，要实现多终端 参与通讯，需要通过本地服务器上的会话交换中心服务器（ Session Transfer Server, 以下简称： STS )代理多个终端与对端进行通讯； 对于对端发送的 语音和视频数据， 首先要通过 STS接收到 STS本地， 再由 STS将该语音 和视频数据进行解码后分别发送给多个终端； 同样也需要 STS对多个终端 发送的数据合并后再发送给对端，因此这就会给 STS所属的本地服务器带 来沉重的负担， 消耗本地服务器的大量资源， 从而影响***的性能。 发明内容
本发明实施例要解决的问题是提供一种多终端通信方法、 ***和装 置，解决现有技术中必须要通过本地服务器上的 STS代理多个终端与对端 进行通讯， 使得给本地服务器带来沉重的负担， 消耗本地服务器的大量资 源的技术缺陷。
为达到上述目的， 本发明实施例一方面提出一种多终端通信方法， 包 括：
接收主叫方向被叫方的语音终端发起的呼叫请求，所述呼叫请求中包 含有视频媒体标识；
建立所述被叫方的语音终端与所述主叫方的语音会话，并根据所述视 频媒体标识建立被叫方的视频终端和所述主叫方的视频会话。
另一方面， 本发明实施例还提供了一种多终端通信***， 包括主叫方 和业务代理服务器，
所述主叫方，用于通过所述业务代理服务器向被叫方的语音终端发起 呼叫请求， 所述呼叫请求中包含有视频媒体标识；
所述业务代理服务器，用于建立所述被叫方的语音终端与所述主叫方 的语音会话， 并根据所述视频媒体标识建立被叫方的视频终端和所述主叫 方的视频会话。
本发明实施例还提供了一种业务代理服务器， 包括请求消息接收模 块、 语音会话创建模块和视频会话创建模块， 所述请求消息接收模块， 用 于接收主叫方向被叫方的语音终端发起的呼叫请求， 所述呼叫请求中包含 有视频媒体标识；
所述语音会话创建模块，用于创建所述被叫方的语音终端与所述主叫 方的语音会话；
所述视频会话创建模块，用于根据所述请求消息接收模块接收的视频 媒体标识建立所述被叫方的视频终端和所述主叫方的视频会话。
本发明实施例的技术方案具有以下优点，因为通过业务代理服务器分 别建立主叫方和被叫方的语音终端的语音会话， 主叫方和被叫方的视频终 端的视频会话， 从而使主叫方和被叫方 （多个终端）之间传送的数据就不 再需要通过本地服务器， 从而减轻本地服务器的负担， 并且通过本发明实 施例只需增加业务代理服务器与主叫方及被叫方之间的信令交互即可， 因 此也不会给业务代理服务器带来负担。 附图说明
图 1为本发明多终端通信方法第一实施例的流程图；
图 2为本发明多终端通信方法第二实施例中 UE注册的信令流程图； 图 3 为本发明多终端通信方法第二实施例中被叫方的视频终端 STB 向 SBF申请订阅绑被叫方的定语音终端的信令流程图；
图 4为本发明多终端通信方法第二实施例中基于 IPTV的多终端通信 方法的信令流程图；
图 5为本发明多终端通信方法第三实施例中基于 IPTV的多终端通信 方法的信令流程图；
图 6为本发明多终端通信***实施例的结构示意图。 具体实施方式
下面结合附图和实施例， 对本发明的具体实施方式作进一步详细描 述。
方法第一实施例
图 1为本发明多终端通信方法第一实施例的流程图， 如图 1所示， 本 实施例的方法包括：
步骤 101、 接收主叫方向被叫方的语音终端发起的呼叫请求， 该呼叫 请求中包含有视频媒体标识；
步骤 102、 建立被叫方的语音终端与主叫方的语音会话， 并根据该视 频媒体标识建立被叫方的视频终端和主叫方的视频会话。
本发明多终端通信方法第一实施例主要在于通过业务代理服务器 ( Service Broker Function, 以下简称： SBF ) 分别建立主叫方和被叫方多 个终端之间的会话， 假设被叫方包括 STB和手机终端， 则可通过 SBF建 立 STB与主叫方视频会话，建立手机终端与主叫方的语音会话，这样主叫 方和被叫方 （多个终端）之间传送的数据就不需要通过本地服务器， 从而 减轻本地服务器的负担， 并且通过本发明多终端通信方法第一实施例只需 增加 SBF与主叫方及被叫方之间的信令交互即可， 因此也不会给 SBF带 来负担。
方法第二实施例
为了便于理解本发明多终端通信方法第一实施例所提出的技术方案， 本发明多终端通信方法第二实施例提出了一种实际生活中的应用场景， 在 该场景中，被叫方的多终端具体为 STB和用户的固定电话，但是需要说明 的是下述应用场景仅为了对本发明多终端通信方法第一实施例所提出的 技术方案能够有一个较好的了解， 但并不意味着本发明多终端通信方法第 一实施例只能够应用于此类场景。
设用户 A家里的 STB与固定电话进行了绑定， 而且在 STB上订阅 了固定电话的通话状态，并且用户 A家里的固定电话不具备视频接收展现 能力。 当用户 B向用户 A家里的固定电话发起视频电话请求时， 用户 A 接听电话， 同时在电视上显示有用户 B的视频过来， 询问是否接收， 用户 A选择接收，然后用户 A通过固定电话与用户 B对话同时通过电视观看用 户 B那边传来的视频。 如果当用户 B向用户 A家里的固定电话发起视频 电话请求时， 用户 A家里的电视没有开机， 用户 A首先接听电话， 用户 B 告诉用户 A还能发自己的视频过来， 于是用户 A就能够打开电视， 这时 屏幕上弹出窗口询问是否接收用户 B的视频， 用户 A选择接收， 然后用 户 A通过固定电话与用户 B对话同时通过电视观看用户 B那边传来的视 频。
在基于 IP多媒体*** (IP Multimedia Subsystem, 以下简称： IMS)的 IPTV ***架构中， 用户所使用的语音终端可以包括 STB, 手机、 固定电 话等； 网络电视服务控制功能 ( IPTV Service Control Function , 以下简称： IPTV SCF )用于管理 IPTV的相关业务； SBF为融合业务的关键网元， 为 各种不同业务（如 IPTV业务与语音业务）之间的公共接口。 网络电视媒 体功能 ( IPTV Media Function )包括 Media Control和 Media Delivery两部 分， 用于媒体控制和传输。
在本发明多终端通信方法第二实施例中首先需要用户终端 （User Terminal , 以下简称： UE ) 在 SBF 和通用电信应用服务器 （ General Telecommunication Application Server, 以下简称： GTAS ) 上注册成功。 GTAS相当于电话***中的呼叫控制 /处理服务器， 负责控制主叫与被叫之 间的信令， 例如振铃、 摘机、 挂机等。 其中本发明多终端通信方法第二实 施例提出了以下的 UE注册流程，
图 2为本发明多终端通信方法第二实施例中 UE注册的信令流程图， 如图 2所示， 该过程可以包括以下步骤：
步骤 S401 , UE向 IMS核心层发送注册 4艮文。
步骤 S402, IMS核心层向 UE返回 SIP 401消息， 由服务器向客户端 返回， 表示该客户端未被授权。 （当 UE第一次发送请求上去的时候， 如 果返回 SIP 401消息说明该 UE未授权， 这时 UE需要再发一次注册请求， 其中需要携带自己的认证信息， 例如用户名、 密码等， 这里之所以要发送 两次注册报文是 SIP协议的规定） 。
步骤 S403 , UE向 IMS核心层发送注册 4艮文。
步骤 S404, IMS核心向 UE返回 200 OK：。
步骤 S405 ,根据初始过滤标准 ( Initial Filter Criteria,以下简称： IFC ) , 发起第三方注册。 IFC是存储在归属用户服务器（ Home Subscriber Server, 以下简称： HSS ) 的用户签约数据中的一部分， 在用户注册时下载到为用 户分配的服务呼叫会话控制功能（ Serving CallSession Control Function, 以 下简称： S-CSCF ) ; IFC按照不同优先级定义了业务触发的条件和目的应 用服务器 （Application Server, 以下简称： AS ) , S-CSCF在处理用户业 务请求时进行 IFC匹配检测，符合触发条件则向指定的 AS触发，使得 AS 可以对该次业务按照 AS内既定的业务逻辑进行控制。 所谓第三方注册是 指 S-CSCF根据用户的 IFC 自动帮助用户发起的注册， 也就是说用户其实 只是到 IMS核心层上来进行注册的， 但是 IMS核心层根据 IFC发现用户 还应该到某个服务器上进行注册， 就自动的帮用户进行注册了。
步骤 S406, IMS核心层代理 UE向 SBF发送注册请求。
步骤 S407 , SBF向 IMS核心层返回 200 OK,指示该 UE已注册成功。 步骤 S408 , IMS核心层代理 UE向 GTAS发送注册请求。
步骤 S409, GTAS向 IMS核心层返回 200 OK, 指示该 UE已注册成 功。
为了便于描述被叫方的终端包括 STB和电话， 其中需要在 SBF中设 置被叫方的视频终端 STB和被叫方的语音终端（如固定电话、 小灵通和手 机等）的绑定关系， 并且需要被叫方的视频终端 STB能够获知与其绑定的 被叫方的语音终端的通话状态，因此就需要被叫方的视频终端 STB向 SBF 发送订阅请求，请求被叫方的视频终端 SBF在接收到对与其绑定的被叫方 的语音终端的呼叫后， 能够将相应的通话请求通知所述被叫方的视频终端
STB。
图 3 为本发明多终端通信方法第二实施例中被叫方的视频终端 STB 向 SBF申请订阅绑定被叫方的语音终端的信令流程图， 如图 3所示， 该实 施例中被叫方的视频终端 STB已经在 IPTV SCF上注册成功。
步骤 S501 , 被叫方的视频终端 STB通过 subscribe命令向 SBF发起 订阅请求， 其中该订阅请求包括与 STB绑定的语音终端的信息。
步骤 S502, SBF检查根据订阅请求包中携带的被叫方的语音终端的 信息，判断该被叫方的语音终端是否为与该被叫方的视频终端 STB存在绑 定关系，如果存在绑定关系则决定接受被叫方的视频终端 STB的订阅请求 并执行步骤 S503 , 否则拒绝该被叫方的视频终端 STB的订阅请求。
步骤 S503 , SBF通过 notify命令向被叫方的视频终端 STB返回订阅 成功消息。在被叫方的视频终端 STB订阅成功后，如果有主叫方向与被叫 方的视频终端 STB绑定的被叫方的语音终端发起呼叫请求， 则 SBF也会 将该呼叫请求转发给被叫方的视频终端 STB。
方法第四实施例
图 4为本发明多终端通信方法第二实施例中基于 IPTV的多终端通信 方法的信令流程图， 如图 4 所示， 该实施例中， 被叫方的视频终端 STB 已经在 SBF上成功订阅了与其绑定的被叫方的语音终端的会话状态，该实 施例中被叫方至少包括一个被叫方的语音终端（如固定电话、 小灵通和手 机等） 和一个被叫方的视频终端 （如 STB ) 。 包括以下步骤：
步骤 S601 , 主叫方向 SBF 发送呼叫请求 INVITE 消息， 其中， 该 INVITE消息中的会话描述协议 （ Session Description Protocol , 以下简称： SDP ) 1 信息中包含有视频媒体标识， 标识该主叫方请求发起的是一个音 视频会话。 该 SDP1信息还包含有主叫方的能力信息， 如该主叫方是否支 持视频会话等。 步骤 S602, SBF接收到主叫方的 INVITE消息后， 判断该 INVITE消 息中 的 SDP1信息是否包含视频媒体标识， 如果包含该视频媒体标识， 则 SBF记录此次视频会话请求。 其中， SBF也可根据 SDP1信息中的主叫方 能力信息判断该主叫方是否能够支持视频会话， 如果该主叫方不支持视频 会话， 则即使该主叫方发送的 SDP1信息中包含有视频媒体标识， SBF也 不会为该主叫方建立视频会话。
步骤 S603 , SBF将 INVITE消息转发给被叫方的语音终端。
步骤 S604,被叫方的语音终端摘机后，向 SBF返回响应消息 200 OK, 该响应消息中包含该被叫方的语音终端的 SDP2信息， 该 SDP2信息同样 也包含该语音终端的能力信息。
步骤 S605 , SBF根据响应消息中被叫方的语音终端的 SDP2信息判 断该被叫方的语音终端是否支持视频功能， 如果该被叫方的语音终端不支 持视频功能， 则 SBF将被叫方的语音终端的响应消息转发给主叫方， 主叫 方在收到该响应消息后， 建立和被叫方的语音终端之间的语音会话。
步骤 S606, SBF根据步骤 S602中记录的视频会话请求查找与该被叫 方的语音终端存在绑定关系的被叫方的视频终端， 并根据主叫方向被叫方 的语音终端发送的呼叫请求通知该被叫方的视频终端发起视频会话请求。 具体为通过通知 （NOTIFY ) 消息 （例如： Notify <Request-URI:STB> Body: state为 confirmed, call-id, fromtag, totag ) 通知该被叫方的视频终 端发起视频会话请求。
步骤 S607, 被叫方的视频终端在收到 SBF的通知消息后， 在被叫方 的视频终端上向用户显式有视频会话请求， 并询问用户是否同意连接到主 叫方的视频。 作为本发明实施例的优选方案， 可以接收到主叫方的会话请 求之后， 启动定时器， 在定时器超时后还未收到用户同意的指令， 则默认 为拒绝此次视频会话请求。 如果用户不同意此次视频会话请求， 则不向 SBF发送加入视频会话请求。 步骤 S608, 如果用户同意此次视频会话请求， 则被叫方的视频终端 向 SBF发送视频会话加入请求。 具体为被叫方的视频终端向 SBF发送视 频 会话请 求 INVITE 消 息 ， 并 填 写 Join 头 域 ， 如 Join: xxx;to-tag=xxx;from-tag=xxx , 该 Join头域用于通知 SBF,表示视频终端希 望加入一个已经存在的会话， 其中该视频会话请求 INVITE消息也携带有 该被叫方的视频终端的 SDP信息 （SDP3 ) , 该 SDP3 中包含有被叫方的 视频终端的视频描述信息。
步骤 S609, SBF在接收被叫方的视频终端到的视频会话加入请求后， 根据该视频会话加入请求中的 Join 头域匹配到主叫方和被叫方的语音终 端已存在的语音会话中， 并将被叫方的视频终端的视频能力和语音终端的 语音能力进行合并， 合并后向主叫方发送 REINVITE请求， 请求主叫方再 建立一个视频会话， 具体为： 将 SDP3中的视频描述信息添加到 SDP2中 生成一个新的 SDP信息 SDP4, 并通过 REINVITE请求向主叫方发送， 该 REINVITE请求中携带有 SDP4, 这样主叫方就能够直到请求建立视频会 话的对端是已经建立了语音会话的被叫方。
步骤 S610, 主叫方在收到 REINVITE请求后， 向 SBF返回 200 OK 的响应消息， 该响应消息中的 SDP信息 （SDP5 ) 中携带有主叫方的视频 描述信息及语音描述信息。
步骤 S611 , SBF在接收到主叫方返回的响应消息后， 将该响应消息 中 SDP5中的主叫方的语音描述信息去除，仅留下主叫方的视频描述信息， 并将去除语音描述信息后的新的 SDP5通过 200 OK返回给被叫方的视频 终端。 因为如果不将主叫方的语音描述信息去除， 则不仅会建立主叫方与 被叫方的视频终端的视频会话， 也会建立主叫方与被叫方的视频终端的语 音会话。
步骤 S612,被叫方的视频终端接收到 SBF的 INVITE请求后 ,向 SBF 返回 ACK确认消息。 步骤 S613 , SBF将被叫方的视频终端的 ACK确认消息转发给主叫方， 从而建立主叫方和被叫方的视频终端之间的视频会话。
这样通过上述实施例 SBF控制被叫方的视频终端与主叫方之间重新 建立视频会话， 使得没有视频接收能力的被叫方的语音终端能够将与主叫 方的视频会话转接到与该被叫方的语音终端绑定的被叫方的视频终端上， 对于 SBF 来说只需为主叫方和被叫方的视频终端建立相应的视频会话即 可， 无需像现有技术那样需要代理被叫方的多个终端与主叫方进行会话， 因此本发明实施例所提出的方法在不给 SBF造成负担的基础上，能够有效 解决多终端与主叫方通讯的问题。
图 5为本发明多终端通信方法第三实施例中基于 IPTV的多终端通信 方法的信令流程图， 如图 5所示， 该实施例中当主叫方发起会话请求时被 叫方的视频终端并未上线，由 SBF接收到主叫方向被叫方的被叫方的语音 终端发出提醒， 提醒被叫方用户打开被叫方的视频终端， 在被叫方的视频 终端开启后，向 SBF发送订阅与其绑定的被叫方的语音终端的通话状态的 请求， 在订阅成功后 SBF建立被叫方的视频终端与主叫方的视频会话，从 而将与主叫方的视频会话转接到与该被叫方的语音终端绑定的被叫方的 视频终端上。
步骤 S701 , 主叫方向 SBF 发送呼叫请求 INVITE 消息， 其中， 该 INVITE消息中的 SDP1信息中包含有视频媒体标识， 标识该主叫方请求 发起的是一个音视频会话， 而不仅仅是音频会话。 该 SDP1信息还包含有 主叫方的能力信息， 如该主叫方是否支持视频会话等。
步骤 S702, SBF接收到主叫方的 INVITE消息后， 判断该 INVITE消 息中 的 SDP1信息是否包含视频媒体标识， 如果包含该视频媒体标识， 则 SBF记录此次视频会话请求。 其中， SBF也可根据 SDP1信息中的主叫方 能力信息判断该主叫方是否能够支持视频会话， 如果该主叫方不支持视频 会话， 则即使该主叫方发送的 SDP1 信息中包含有所述视频媒体标识， SBF也不会为该主叫方建立视频会话。
步骤 S703 , SBF将 INVITE消息转发给被叫方的语音终端。
步骤 S704,被叫方的语音终端摘机后，向 SBF返回响应消息 200 OK, 该响应消息中包含该被叫方的语音终端的 SDP2信息， 该 SDP2信息同样 也包含该被叫方的语音终端的能力信息。
步骤 S705 , SBF根据响应消息中被叫方的语音终端的 SDP2信息判 断该被叫方的语音终端是否支持视频功能， 如果该被叫方的语音终端不支 持视频功能， 则 SBF将被叫方的语音终端的响应消息转发给主叫方， 主叫 方在收到该响应消息后， 建立和被叫方的语音终端之间的语音会话。
步骤 S706, SBF根据步骤 S602中记录此次视频会话请求， SBF查找 与该被叫方的语音终端存在绑定关系的被叫方的视频终端， 并判断该被叫 方的视频终端是否开机， 在本实施例中视频终端已关机， 因此 SBF通过被 叫方的语音终端提示被叫方用户打开视频终端。
步骤 S707, 被叫方用户在收到 SBF的提示消息后， 如果愿意接收主 叫方的视频请求， 则打开被叫方的视频终端。 被叫方的视频终端开启后， 首先需要在 IPTV SCF上注册成功。
步骤 S708 , 被叫方的视频终端在注册成功之后， 向 SBF 发送 SUBSCRIBE请求， 请求订阅与其绑定的被叫方的语音终端的通话状态。
步骤 S709, SBF接收被叫方的视频终端的 SUBSCRIBE请求， 并查 询该被叫方的视频终端与其请求订阅的被叫方的语音终端是否存在绑定 状态， 如果存在绑定状态， 则允许该被叫方的视频终端订阅被叫方的语音 终端的通话状态。 并通知该被叫方的视频终端发起视频会话请求。 具体为 通过 NOTIFY 消息 （例如： Notify <Request-URI:STB> Body: state 为 confirmed, call-id, fromtag, totag )通知该被叫方的视频终端发起视频会 话请求。
步骤 S710, 被叫方的视频终端在收到 SBF的视频会话请求后， 在被 叫方的视频终端上向用户显式有视频会话请求， 并询问用户是否同意连接 到主叫方的视频。 作为本实施例的优选方案， 可以接收到主叫方的会话请 求之后， 启动定时器， 在定时器超时后还未收到用户同意的指令， 则默认 为拒绝此次视频会话请求。 如果用户不同意此次视频会话请求， 则不向 SBF发送视频会话加入请求。
步骤 S711 , 如果用户同意此次视频会话请求， 则被叫方的视频终端 向 SBF发送视频会话加入请求。 具体为被叫方的视频终端向 SBF发送视 频 会话请 求 INVITE 消 息 ， 并 填 写 Join 头 域 ， 如 Join: xxx;to-tag=xxx;from-tag=xxx , 该 Join头 i或用于通知 SBF,表示被叫方的视 频终端希望加入一个已经存在的会话， 其中该视频会话请求 INVITE消息 也携带有该被叫方的视频终端的 SDP信息 （SDP3 ) , 该 SDP3 中包含有 被叫方的视频终端的视频描述信息。
步骤 S712, SBF在接收被叫方的视频终端到的视频会话加入请求后， 根据该视频会话加入请求中的 Join 头域匹配到主叫方和被叫方的语音终 端已存在的语音会话中， 并将被叫方的视频终端的视频能力和语音终端的 语音能力进行合并， 合并后向主叫方发送 REINVITE请求， 请求主叫方再 建立一个视频会话， 具体为： 将 SDP3中的视频描述信息添加到 SDP2中 生成一个新的 SDP信息 SDP4, 并通过 REINVITE请求向主叫方发送， 该 REINVITE请求中携带有 SDP4, 这样主叫方就能够直到请求建立视频会 话的对端是已经建立了语音会话的被叫方。
步骤 S713 , 主叫方在收到 REINVITE请求后， 向 SBF返回 200 OK 的响应消息， 该响应消息中的 SDP信息 （SDP5 ) 中携带有主叫方的视频 描述信息及语音描述信息。
步骤 S714, SBF在接收到主叫方返回的响应消息后， 将该响应消息 中 SDP5中的主叫方的语音描述信息去除，仅留下主叫方的视频描述信息， 并将去除语音描述信息后的新的 SDP5通过 200 OK返回给被叫方的视频 终端。 因为如果不将主叫方的语音描述信息去除， 则不仅会建立主叫方与 被叫方的视频终端的视频会话， 也会建立主叫方与被叫方的视频终端的语 音会话。
步骤 S715 ,被叫方的视频终端接收到 SBF的 INVITE请求后，向 SBF 返回 ACK确认消息。
步骤 S716, SBF将被叫方的视频终端的 ACK确认消息转发给主叫方， 从而建立主叫方和被叫方的视频终端之间的视频会话。
图 6为本发明多终端通信***实施例的结构示意图， 如图 6所示， 本 实施例是基于 IPTV的结构示意图， 该***包括主叫方 1和 SBF 3 , 主叫 方 1用于通过 SBF 3向被叫方的语音终端 21发起呼叫请求， 该呼叫请求 中包含有视频媒体标识； SBF 3用于建立被叫方的语音终端 21与主叫方 1 的语音会话， 并根据视频媒体标识通知被叫方的视频终端 22 向主叫方 1 发起视频会话请求， 建立被叫方的视频终端 22和主叫方 1的视频会话。
其中， SBF 3包括请求消息接收模块 31、 语音会话创建模块 32、 通知 模块 33和视频会话创建模块 34, 请求消息接收模块 31用于接收主叫方 1 向被叫方的语音终端 21 发起的呼叫请求， 该呼叫请求中包含有视频媒体 标识； 语音会话创建模块 32用于创建被叫方的语音终端 21与主叫方 1的 语音会话； 通知模块 33 用于根据呼叫请求中的视频媒体标识通知被叫方 的视频终端 22向主叫方 1发起视频会话请求； 视频会话创建模块 34用于 建立被叫方的视频终端 22和主叫方 1的视频会话。
其中， SBF 3还包括订阅请求接收模块 35、 绑定关系查询模块 36和 订阅消息返回模块 37, 订阅请求接收模块 35用于接收被叫方的视频终端 22发起的订阅请求， 该订阅请求中携带有被叫方的视频终端 22请求订阅 的被叫方的语音终端 21的标识； 绑定关系查询模块 36用于根据被叫方的 语音终端 21 的标识， 检测被叫方的语音终端 21 与被叫方的视频终端 22 是否存在绑定关系； 订阅消息返回模块 37用于在绑定关系查询模块 36判 断被叫方的语音终端 21与被叫方的视频终端 22存在绑定关系后， 向被叫 方的视频终端 22返回订阅成功的消息。
其中， SBF 3还可以包括加入请求接收模块 38 , 匹配合并模块 39和 去除模块 40,加入请求接收模块 38用于接收被叫方的视频终端 22发送的 视频会话加入请求， 请求加入被叫方的语音终端 21与主叫方 1 的语音会 话， 该视频会话加入请求携带有被叫方的视频终端 22 的视频能力描述信 息； 匹配合并模块 39用于根据该视频会话加入请求将被叫方的视频终端 22匹配到主叫方 1与被叫方的语音终端 21的语音会话， 并将被叫方的视 频终端 22的视频能力描述信息与被叫方的语音终端 21的语音能力描述信 息合并， 向主叫方 1发送重请求消息； 去除模块 40用于接收主叫方 1 的 确认消息后， 将确认消息中的语音部分去除， 建立被叫方的视频终端 22 与主叫方 1的视频会话。
其中， SBF 3还可以进一步包括判断模块 41和开启提示模块 42 , 判 断模块 41用于在请求消息接收模块 31接收到主叫方 1向被叫方的语音终 端 22发起的呼叫请求， 且该呼叫请求中包含有视频媒体标识后， 判断与 被叫方的语音终端 21绑定的被叫方的视频终端 22是否上线； 开启提示模 块 42用于在判断模块 41判断被叫方的视频终端 22未上线时， 向被叫方 的语音终端 21发送消息提示用户开启被叫方的视频终端 22。
本实施例能够通过 SBF分别建立主叫方和被叫方的语音终端的语音 会话，主叫方和被叫方的视频终端的视频会话，从而使主叫方和被叫方（多 个终端）之间传送的数据就不需要通过本地服务器， 从而减轻本地服务器 的负担，并且通过本实施例只需增加 SBF与主叫方及被叫方之间的信令交 互即可， 因此也不会给 SBF带来负担。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本 发明可借助软件加必需的通用硬件平台的方式来实现， 当然也可以通过硬 件， 但很多情况下前者是更佳的实施方式。 基于这样的理解， 本发明的技 术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式 体现出来， 该计算机软件产品存储在一个存储介质中， 包括若干指令用以 使得一台计算机设备（可以是个人计算机， 服务器， 或者网络设备等）执 行本发明各个实施例所述的方法。
以上所述仅是本发明的优选实施方式，应当指出， 对于本技术领域的 普通技术人员来说， 在不脱离本发明原理的前提下， 还可以做出若干改进 和润饰， 这些改进和润饰也应视为本发明的保护范围。

Claims

权 利 要 求
1、 一种多终端通信方法， 其特征在于， 包括：
接收主叫方向被叫方的语音终端发起的呼叫请求，所述呼叫请求中包 含有视频媒体标识；
建立所述被叫方的语音终端与所述主叫方的语音会话，并根据所述视 频媒体标识建立被叫方的视频终端和所述主叫方的视频会话。
2、 如权利要求 1所述多终端通信方法， 其特征在于， 还包括： 向所 述被叫方的视频终端提供所述被叫方的语音终端的会话状态。
3、 如权利要求 1所述多终端通信方法， 其特征在于， 在所述根据所 述视频媒体标识建立被叫方的视频终端和所述主叫方的视频会话之前 , 还 包括：
根据所述视频媒体标识通知所述被叫方的视频终端向所述主叫方发 起视频会话请求；
接收所述被叫方的视频终端向所述主叫方发起的视频会话请求。
4、 如权利要求 2所述多终端通信方法， 其特征在于， 所述向所述被 叫方的视频终端提供所述被叫方的语音终端的会话状态具体为：
接收所述被叫方的视频终端发起的订阅请求，所述订阅请求中携带有 所述被叫方的视频终端请求订阅的所述被叫方的语音终端的标识；
根据所述被叫方的语音终端的标识 ,检测所述被叫方的语音终端与所 述被叫方的视频终端存在绑定关系， 并向所述被叫方的视频终端返回订阅 成功的消息。
5、 如权利要求 4所述多终端通信方法， 其特征在于， 所述被叫方的 视频终端发起的订阅请求具体为：
所述被叫方的视频终端通过 "subscribe"命令向业务代理服务器发起 的订阅请求；
所述向所述被叫方的视频终端返回订阅成功的消息具体为： 通过 "notify" 命令向所述被叫方的视频终端返回订阅成功消息。
6、 如权利要求 1所述多终端通信方法， 其特征在于， 还包括： 所述 被叫方的语音终端注册成功。
7、 如权利要求 1所述多终端通信方法， 其特征在于， 所述根据所述 视频媒体标识建立被叫方的视频终端和所述主叫方的视频会话具体为： 接收所述被叫方的视频终端发送的视频会话加入请求，请求加入所述 被叫方的语音终端与所述主叫方的语音会话， 所述视频会话加入请求携带 有所述被叫方的视频终端的视频能力描述信息；
根据所述视频会话加入请求将所述被叫方的视频终端匹配到所述主 叫方与所述被叫方的语音终端的语音会话， 并将所述被叫方的视频终端的 视频能力描述信息与所述被叫方的语音终端的语音能力描述信息合并， 向 所述主叫方发送重请求消息；
接收所述主叫方的确认消息后，将所述确认消息中的语音能力描述信 息去除， 建立所述被叫方的视频终端与所述主叫方的视频会话。
8、 如权利要求 7所述多终端通信方法， 其特征在于， 所述请求加入 所述被叫方的语音终端与所述主叫方的语音会话具体为：
根据所述被叫方的视频终端填写的 "Join" 头域确定所述被叫方的视 频终端需要加入所述被叫方的语音终端与所述主叫方的语音会话。
9、 如权利要求 7所述多终端通信方法， 其特征在于， 所述被叫方的 视频终端的视频能力描述信息包括所述被叫方的视频终端的视频接收能 力信息， 或， 所述被叫方的视频终端的视频接收能力信息和所述被叫方的 视频终端的视频发送能力信息。
10、 如权利要求 1所述多终端通信方法， 其特征在于， 所述根据所述 视频媒体标识建立被叫方的视频终端和所述主叫方的视频会话之前， 还包 括：
判断所述被叫方的视频终端未上线，则向所述被叫方的语音终端发送 消息， 提示开启所述被叫方的视频终端。
1 1、 如权利要求 10所述多终端通信方法， 其特征在于， 所述向所述 被叫方的语音终端发送消息， 提示开启所述被叫方的视频终端之后， 还包 括：
所述被叫方的视频终端开启后，向所述被叫方的视频终端提供所述被 叫方的语音终端的会话状态。
12、 一种多终端通信***， 其特征在于， 包括主叫方和业务代理服务 器，
所述主叫方，用于通过所述业务代理服务器向被叫方的语音终端发起 呼叫请求， 所述呼叫请求中包含有视频媒体标识；
所述业务代理服务器，用于建立所述被叫方的语音终端与所述主叫方 的语音会话， 并根据所述视频媒体标识建立被叫方的视频终端和所述主叫 方的视频会话。
13、 一种业务代理服务器， 其特征在于， 包括请求消息接收模块、 语 音会话创建模块和视频会话创建模块，
所述请求消息接收模块，用于接收主叫方向被叫方的语音终端发起的 呼叫请求， 所述呼叫请求中包含有视频媒体标识；
所述语音会话创建模块，用于创建所述被叫方的语音终端与所述主叫 方的语音会话；
所述视频会话创建模块，用于根据所述请求消息接收模块接收的视频 媒体标识建立所述被叫方的视频终端和所述主叫方的视频会话。
14、 如权利要求 13所述业务代理服务器， 其特征在于， 还包括： 通 知模块， 用于根据所述请求消息接收模块接收的呼叫请求中的视频媒体标 识通知所述被叫方的视频终端向所述主叫方发起视频会话请求。
15、 如权利要求 13所述业务代理服务器， 其特征在于， 还包括： 订 阅请求接收模块、 绑定关系查询模块和订阅消息返回模块，
所述订阅请求接收模块，用于接收所述被叫方的视频终端发起的订阅 请求， 所述订阅请求中携带有所述被叫方的视频终端请求订阅的所述被叫 方的语音终端的标识； 所述绑定关系查询模块， 用于根据所述被叫方的语音终端的标识，检 测所述被叫方的语音终端与所述被叫方的视频终端是否存在绑定关系； 所述订阅消息返回模块，用于在所述绑定关系查询模块判断所述被叫 方的语音终端与所述被叫方的视频终端存在绑定关系后， 向所述被叫方的 视频终端返回订阅成功的消息。
16、 如权利要求 13所述业务代理服务器， 其特征在于， 还包括： 加 入请求接收模块， 匹配合并模块和去除模块，
所述加入请求接收模块，用于接收所述被叫方的视频终端发送的视频 会话加入请求， 请求加入所述被叫方的语音终端与所述主叫方的语音会 话， 所述视频会话加入请求携带有所述被叫方的视频终端的视频能力描述 信息；
所述匹配合并模块，用于根据所述视频会话加入请求将所述被叫方的 视频终端匹配到所述主叫方与所述被叫方的语音终端的语音会话， 并将所 述被叫方的视频终端的视频能力描述信息与所述被叫方的语音终端的语 音能力描述信息合并， 向所述主叫方发送重请求消息；
所述去除模块， 用于接收所述主叫方的确认消息后， 将所述确认消息 中的语音能力描述信息去除， 建立所述被叫方的视频终端与所述主叫方的 视频会话。
17、 如权利要求 13所述业务代理服务器， 其特征在于， 还包括： 判 断模块和开启提示模块，
所述判断模块， 用于判断所述被叫方的视频终端是否上线； 所述开启提示模块，用于在所述判断模块判断所述被叫方的视频终端 未上线时， 向所述被叫方的语音终端发送消息， 提示开启所述被叫方的视 频终端。
PCT/CN2008/073608 2007-12-25 2008-12-19 Procédé, système et appareil de communication multiterminal WO2009082945A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP08865936A EP2107852A4 (en) 2007-12-25 2008-12-19 COMMUNICATION METHOD WITH MULTIPLE DEVICES, SYSTEM AND DEVICE
US12/481,327 US20090244255A1 (en) 2007-12-25 2009-06-09 Method, system and apparatus for multi-terminal communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710301347.X 2007-12-25
CN200710301347XA CN101472235B (zh) 2007-12-25 2007-12-25 一种多终端通信方法、***和装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/481,327 Continuation US20090244255A1 (en) 2007-12-25 2009-06-09 Method, system and apparatus for multi-terminal communication

Publications (1)

Publication Number Publication Date
WO2009082945A1 true WO2009082945A1 (fr) 2009-07-09

Family

ID=40823780

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/073608 WO2009082945A1 (fr) 2007-12-25 2008-12-19 Procédé, système et appareil de communication multiterminal

Country Status (4)

Country Link
US (1) US20090244255A1 (zh)
EP (1) EP2107852A4 (zh)
CN (1) CN101472235B (zh)
WO (1) WO2009082945A1 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102131080B (zh) * 2010-01-15 2013-02-13 华为技术有限公司 一种视频传输方法、***及光网络设备
DE102010014351A1 (de) * 2010-04-09 2011-10-13 S. Siedle & Söhne Telefon- und Telegrafenwerke OHG Verfahren zum Betreiben einer Hauskommunikationsanlage und Hauskommunikationsanlage
WO2012055108A1 (en) * 2010-10-28 2012-05-03 Socaller Limited Method and arrangements for displaying information to a user
CN102547416B (zh) * 2010-12-27 2015-05-13 佛山络威网络技术有限公司 一种手机与电视分载媒体的方法
CN102340649A (zh) * 2011-10-24 2012-02-01 华为技术有限公司 无绳可视电话通话控制方法和无绳可视电话
CN103378984B (zh) * 2012-04-26 2019-08-23 中兴通讯股份有限公司 个人网管理方法和***
CN102904882B (zh) * 2012-09-24 2018-08-10 南京中兴新软件有限责任公司 随机呼叫的转发方法及装置
CN103347306B (zh) * 2013-06-24 2015-11-18 腾讯科技（深圳）有限公司 一种多个终端建立关联的方法、***及装置
CN104426854A (zh) * 2013-08-23 2015-03-18 中兴通讯股份有限公司 一种实现代理通话的方法及***
US20160242072A1 (en) * 2015-02-18 2016-08-18 Qualcomm Incorporated Handling over-sized call setup messages
CN105120368A (zh) * 2015-08-26 2015-12-02 无锡华海天和信息科技有限公司 一种能够提示来电通知的网络视频电话***及其实现方法
CN105763537A (zh) * 2016-01-29 2016-07-13 宇龙计算机通信科技(深圳)有限公司 多方通话的方法及装置
CN106657053B (zh) * 2016-12-19 2019-11-08 中国人民解放军国防信息学院 一种基于端状态迁移的网络安全防御方法
US20180183933A1 (en) * 2016-12-23 2018-06-28 Qualcomm Incorporated Techniques and apparatuses for call handling during a user equipment ringing state
CN107222706B (zh) * 2017-06-29 2019-12-13 北京奇艺世纪科技有限公司 一种视频预览方法及***
CN109862306B (zh) * 2019-01-14 2022-10-14 平安科技（深圳）有限公司 视频显示方法、电子装置、计算机设备及存储介质
CN112671773A (zh) * 2020-12-24 2021-04-16 厦门亿联网络技术股份有限公司 一种voip设备中多终端的集成方法、装置、设备及存储介质
CN113225512B (zh) * 2021-04-26 2023-07-25 北京新方通信技术有限公司 一种视频呼叫中心坐席终端音视频分流方法和***

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070059808A (ko) * 2005-12-07 2007-06-12 한국전자통신연구원 셋톱박스에서의 영상 전화 연결 장치 및 방법
CN101090474A (zh) * 2006-06-15 2007-12-19 王欣 基于多种传输媒体协同工作的可视电话的实现方法和设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023730A1 (en) * 2001-07-27 2003-01-30 Michael Wengrovitz Multiple host arrangement for multimedia sessions using session initiation protocol (SIP) communication
US7532628B2 (en) * 2002-12-30 2009-05-12 Cisco Technology, Inc. Composite controller for multimedia sessions
KR101155224B1 (ko) * 2005-03-09 2012-06-13 삼성전자주식회사 Ｓｉｐ/ｉｐ 코어 네트워크에서 세션 분리 방법 및 서버 및 단말

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070059808A (ko) * 2005-12-07 2007-06-12 한국전자통신연구원 셋톱박스에서의 영상 전화 연결 장치 및 방법
CN101090474A (zh) * 2006-06-15 2007-12-19 王欣 基于多种传输媒体协同工作的可视电话的实现方法和设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2107852A4 *

Also Published As

Publication number Publication date
EP2107852A1 (en) 2009-10-07
CN101472235B (zh) 2012-08-15
CN101472235A (zh) 2009-07-01
US20090244255A1 (en) 2009-10-01
EP2107852A4 (en) 2011-04-20

Similar Documents

Publication Publication Date Title
WO2009082945A1 (fr) Procédé, système et appareil de communication multiterminal
US7167468B2 (en) Internet protocol telephony voice/video message deposit and retrieval
US10009389B2 (en) Scalable conference bridge
EP2107714B1 (en) Method and apparatus for implementing a multimedia ring back tone service and multimedia caller identification service
EP2590376B1 (en) Method, apparatus and system for cross-platform conference convergence
KR101458634B1 (ko) 사전 설정 세션을 관리하기 위한 방법 및 이를 구현하기위한 ＰｏＣ 시스템과 ＰｏＣ 단말
US8953583B2 (en) Method and system for selective call forwarding based on media attributes in telecommunication network
US20080043717A1 (en) Exchange Protocol For Combinational Multimedia Services
US7730127B2 (en) Method, system and apparatus for video sharing
WO2009018755A1 (fr) Procédé de session multi-terminal, système de communication et dispositifs associés
WO2009024092A1 (fr) Procédé et système permettant la commande d&#39;autorisation de ressource de service
WO2007068206A1 (fr) Procede et reseau de mise en marche d&#39;informations concernant la capacite de session
US9071690B2 (en) Call transfer processing in SIP mode
WO2007095855A1 (fr) Procédé et entité réseau de négociation d&#39;un paramètre de type média
EP2214376B1 (en) Management method, system and apparatus for specific apparatus in multimedia session
CN102378355A (zh) 一种ims多媒体会议终端切换方法和装置
WO2008080297A1 (fr) Procédé, équipement et système pour mettre en rapport une session
WO2015176746A1 (en) A method and apparatus for establishing an additional session to an anonymous user
WO2007140699A1 (fr) Procédé et appareil de mise à jour des données signées d&#39;abonné
WO2008119278A1 (fr) Procédé, terminal et dispositif réseau pour le changement d&#39;état de domaine à commutation de paquets
EP1672867A1 (en) Method to the fast and reliable transfer of large amount of data between mobile radio users involved in a SIP session
CN103078853A (zh) 一种基于会话初始化协议的数据传输方法和相应装置
WO2010111946A1 (zh) 一种点击拨号中控制会话媒体类型的方法和装置
WO2007082493A1 (fr) Procédé et entité de réseau pour le traitement du contenu de message de protocole d&#39;ouverture de session

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2008865936

Country of ref document: EP

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

Ref document number: 08865936

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE