Methods, systems, and computer-readable media for optimized attended call transfer between session border controllers (SBCs) with transfer target session reuse

By establishing media sessions between SBCs in a VoIP network and using custom signaling, the problem of call transfer failure under session load balancing was solved, and call transfer between SBCs was successful and efficiency was improved.

CN116746133BActive Publication Date: 2026-03-03ORACLE INT CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202180091296.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2021-01-19
Filing Date
2021-12-17
Publication Date
2026-03-03
Estimated Expiration
2041-12-17

AI Technical Summary

Technical Problem

In VoIP networks, existing SIP call forwarding methods cannot effectively achieve call forwarding when someone answers under session load balancing, resulting in call forwarding attempts failing.

Method used

By establishing a media session between the first and second SBCs, signaling optimization using custom headers and SIP invitation messages is achieved, enabling the reuse of the target session, including exchanging custom information between SBCs to support re-invitation methods.

Benefits of technology

Session load balancing between SBCs in a load-balanced network is achieved, the call transfer process is optimized, and the successful execution of call transfer is ensured.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116746133B_ABST
    Figure CN116746133B_ABST
Patent Text Reader

Abstract

A first SBC establishes a first media session between a transferor and a transferee. A second SBC establishes a second media session between the transferor and a transfer target. The first SBC receives a transfer message initiated by the transferor and determines that a dialog ID in the transfer message does not correspond to a media session currently being handled by the first SBC. The first SBC sends a SIP invite message to a plurality of SBCs in a load sharing group with the first SBC, including the second SBC. The SIP invite message includes the dialog ID associated with the second media session, which triggers the second SBC to reuse the second media session to establish a media session between the transferee and the transfer target.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Priority requirements

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 152,731, filed January 19, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter described herein relates to call transfer. More specifically, the subject matter described herein relates to methods, systems, and computer-readable media for optimized inter-SBC call transfer with a target session reuse. Background Technology

[0004] Call transfer, or call forwarding, is a mechanism that reassigns telephone calls from one telephone to another. Each transfer event involves three parties, known as user agents in Voice over Internet Protocol (VoIP) networks. These three parties are:

[0005] Transferor: The party initiating call forwarding;

[0006] The transferee: the party whose call or session is being connected to or transferred to the transfer target; and

[0007] Transfer target: The new party introduced into the conversation with the transferee.

[0008] In the case of VoIP calls, call transfer can be implemented using the Session Initiation Protocol (SIP) Reforge (REFER) method. The SIP reforge method is defined in Internet Engineering Task Force (IETF) Request for Comment (RFC) 3515. One application of the SIP reforge method is call transfer. For example, IETF RFC 3515 states:

[0009] [SIP forwarding methods] can be used to enable many applications, including call forwarding. For example, if Alice is talking to Bob and decides that Bob needs to speak with Carol, Alice can instruct her SIP User Agent (UA) to send a SIP forwarding request to Bob's UA, providing Carol's SIP contact information. Assuming Bob has granted permission, Bob's UA will attempt to call Carol using that contact. Bob's UA will then report whether it successfully connected with Alice's UA.

[0010] In the article cited above, IETF RFC 3515 states that call forwarding can be achieved using the SIP switching method.

[0011] There are two main methods for transferring calls via SIP:

[0012] Blind call forwarding or unanswered call forwarding

[0013] Call forwarding is available.

[0014] In blind call transfer or unanswered call transfer, the transferor provides the transfer target's contact information so that the transferee can directly initiate a call with the transfer target. In answered call transfer, the transferor places the transferee on pause, establishes a call with the transfer target to warn the target of the impending transfer, places the target on pause, and then resumes the transfer by sending a SIP transfer message to the transferee, which includes a replacement header field in the Refer-To header. Then, as part of an INVITE request for a new call, the transferee transmits the replacement header field information to the transfer target. The transfer target uses this information to identify its session with the transferor and associate the session with a new call.

[0015] The SBC executes signaling for establishing and tearing down media sessions between user agents, including signaling for performing answered call forwarding. In an answered call forwarding, the SBC can utilize the SIP Re-INVITE procedure to reuse the media session between the transferor and the transfer target, instead of requiring the transferee to establish a new media session with the transfer target. However, the re-invitation method only works if the SBC using the re-invitation procedure to perform the call forwarding is aware of the media session between the transferor and the transfer target. If the network implements session load balancing, the SBC for the original call between the transferee and the transferor may differ from the SBC for the call between the transferor and the transfer target. In this case, the SBC that established the original call between the transferee and the transferor is unaware of the call between the transferor and the transfer target, and therefore cannot use the re-invitation procedure to reuse the call between the transferor and the transfer target, which may cause the call forwarding attempt to fail.

[0016] Given these difficulties, there is a need for improved methods, systems, and computer-readable media for call forwarding with someone answering in networks in which session load balancing between SBCs is achieved. Summary of the Invention

[0017] A method is provided for optimized, attended call transfer between Session Border Controllers (SBCs) with a transfer target session reuse feature. The method includes: establishing a first media session between a transferor and a transferee at a first SBC. The method further includes: establishing a second media session between a transferor and a transfer target at a second SBC in response to a Session Initiation Protocol (SIP) invitation message initiated by the transferor and routed to the second SBC by a session router. The method further includes: receiving a SIP transfer message initiated by the transferor at the first SBC and including a session ID associated with the second media session; and, in response, determining that the session ID does not correspond to a media session currently being handled by the first SBC, sending SIP invitation messages, including the session ID associated with the second media session, to a plurality of SBCs in a load-sharing group with the first SBC. The method further includes: at the second SBC, receiving a SIP invitation message, identifying the SIP invitation message as a request for call forwarding to a forwarding target with someone available, and in response, sending signaling to the forwarding target and the first SBC to reuse a second media session to establish a media session between the transferee and the forwarding target.

[0018] According to another aspect of the subject matter described herein, establishing a first media session includes establishing a first media session in response to a SIP invitation message initiated by the assignee and forwarded by a session router to a first SBC, the session router using call allocation logic to select the first SBC to handle the first media session.

[0019] According to another aspect of the subject described in this article, based on the call allocation logic of the session router, the SIP invitation message initiated by the transferor is sent to the second SBC.

[0020] According to another aspect of the subject matter described herein, receiving a SIP transfer message includes receiving a SIP transfer message with a replacement header that includes a session ID associated with a second media session.

[0021] According to another aspect of the subject matter described herein, sending a SIP invitation message that includes a conversation ID associated with a second media session includes adding a custom header to the SIP invitation message that indicates that the SIP invitation message will initiate a call forwarding with someone answering the second media session.

[0022] According to another aspect of the subject matter described herein, signaling to the first SBC and the transfer target to reuse the second media session to establish a media session between the transferee and the transfer target includes: sending a SIP re-invitation message to the transfer target, receiving a success response from the transfer target, and in response to receiving the success response from the transfer target, sending a success response to the first SBC.

[0023] According to another aspect of the subject matter described herein, a method for optimized, answered inter-SBC call transfer includes establishing a media session between the first and second SBCs. It should be noted that even if signaling is performed to establish a media session between the first and second SBCs, media packets may not be exchanged on the inter-SBC media session. In other words, "establishing a media session" as described herein includes performing signaling to establish a media session, but does not necessarily involve exchanging media packets on the media session.

[0024] According to another aspect of the subject matter described herein, a method for optimized inter-SBC call transfer with target session reuse includes: at a first SBC, replacing the outer dialogue of a first media session with an outer dialogue of a media session between the first and second SBCs, and at a second SBC, replacing the inner dialogue of a second media session with an inner dialogue of a media session between the first and second SBCs.

[0025] According to another aspect of the subject matter described herein, a method for optimized, answered inter-SBC call transfer with target session reuse includes: at the first SBC, sending a goodbye message to the transferor and releasing resources associated with the external dialogue of the first media session.

[0026] According to another aspect of the subject matter described herein, a method for optimized, answered inter-SBC call transfer with target session reuse includes: at the second SBC, sending a goodbye message to the transferor and releasing resources associated with the intra-talk of the second media session.

[0027] According to another aspect of the subject matter described herein, a system for optimized, answered call transfer between Session Border Controllers (SBCs) with transfer target session reuse is provided. The system includes a first SBC for establishing a first media session between a transferor and a transferee. The system also includes a second SBC for establishing a second media session between the transferor and the transfer target in response to a Session Initiation Protocol (SIP) invitation message initiated by the transferor and routed to the second SBC by a session router. The first SBC is configured to receive a SIP transfer message from the transferor including a session ID associated with the second media session, and, in response, to determine that the session ID does not correspond to a media session currently being handled by the first SBC, to send SIP invitation messages, including the session ID associated with the second SBC, to multiple SBCs in a load-sharing group with the first SBC. The second SBC is configured to receive SIP invitation messages, recognize the SIP invitation messages as requests for call forwarding to the forwarding target where someone is available, and in response, send signaling to the forwarding target and the first SBC to reuse the second media session to establish a media session between the transferee and the forwarding target.

[0028] According to another aspect of the subject matter described herein, a first SBC is configured to establish a first media session in response to a SIP invitation message initiated by the assignee and forwarded to the first SBC by a session router, the session router using call allocation logic to select the first SBC to handle the first media session.

[0029] According to another aspect of the subject matter described herein, a second SBC is configured to establish a second media session in response to a SIP invitation message initiated by the transferor and forwarded to the session router, which uses call allocation logic to select the second SBC to handle the second media session.

[0030] According to another aspect of the subject described in this article, SIP transfer messages include a replacement header that includes a session ID associated with a second media session.

[0031] According to another aspect of the subject matter described herein, the first SBC is configured to include a conversation ID associated with the second media session in a custom header of the SIP invitation message, wherein the custom header indicates that the SIP invitation message will initiate a call forwarding with someone answering the second media session.

[0032] According to another aspect of the subject matter described herein, signaling is sent to the first SBC and the transfer target to reuse the second media session to establish a media session between the transferee and the transfer target. The second SBC is configured to: send a SIP re-invite message to the transfer target, receive a success response from the transfer target, and, in response to receiving the success response from the transfer target, send a success response to the first SBC.

[0033] According to another aspect of the subject matter described herein, the first and second SBCs are configured to establish a media session between the first and second SBCs.

[0034] According to another aspect of the subject matter described herein, a first SBC is configured to replace the external dialogue of a first media session with an external dialogue of a media session between the first and second SBCs; and a second SBC is configured to replace the internal dialogue of a second media session with an internal dialogue of a media session between the first and second SBCs.

[0035] According to another aspect of the subject matter described herein, a first SBC is configured to send a SIP goodbye message to the transferor and release resources associated with the outer dialogue of the first media session, and a second SBC is configured to send a SIP goodbye message to the transferor and release resources associated with the inner dialogue of the second media session.

[0036] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon, which, when executed by a computer's processor, control the computer to perform steps. The steps include: establishing a first media session between a transferor and a transferee at a first session boundary controller (SBC). The steps also include: establishing a second media session between a transferor and a transfer target at a second SBC in response to a Session Initiation Protocol (SIP) invitation message initiated by the transferor and routed to the second SBC by a session router. The steps further include: receiving a SIP transfer message initiated by the transferor at the first SBC and including a session ID associated with the second media session, and in response, determining that the session ID does not correspond to a media session currently being processed by the first SBC, and sending SIP invitation messages, including the session ID associated with the second media session, to a plurality of SBCs in a load-sharing group with the first SBC. The steps further include: at the second SBC, receiving a SIP invitation message, identifying a SIP invitation message requesting a call transfer to the transfer target, and in response, sending signaling to the transfer target and the first SBC to reuse a second media session to establish a media session between the transferee and the transfer target. The subject matter described herein can be implemented in hardware, software, firmware, or any combination thereof. Therefore, the terms “function,” “node,” or “module” as used herein refer to hardware for implementing the described features, which may also include software and / or firmware components. In one exemplary implementation, the subject matter described herein can be implemented using a computer-readable medium having computer-executable instructions stored thereon, which, when executed by a computer’s processor, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits. Furthermore, computer-readable media implementing the subject matter herein can be located on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0037] The subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0038] Figure 1 This is a message flow diagram illustrating the exchange of exemplary messages for call forwarding when a call is answered using a single SBC, wherein the SBC relays messages from the transferor to the transferee to transfer the transferee to the transfer target.

[0039] Figure 2This is a message flow diagram illustrating the exchange of exemplary messages for call forwarding when a call is answered using a single SBC, where the SBC initiates a session with the forwarding target rather than relaying a message to the transferee.

[0040] Figure 3 This is a message flow diagram illustrating the exchange of exemplary messages for call forwarding when someone answers using a single SBC, where the SBC uses a re-invitation process to reuse a previously established session between the transferor and the transfer target;

[0041] Figure 4 This is a message flow diagram illustrating an exemplary message for a failed call forwarding exchange when the initial session and the session with the target reside on different SBCs;

[0042] Figure 5 This is a block diagram showing the SBC and the dialog maintained by the SBC for performing call forwarding when someone answers;

[0043] Figure 6 This is a message flow diagram showing the exchange of exemplary messages for call forwarding when someone answers, where the original session and the session with the forwarding target reside on different SBCs of the reuse target session;

[0044] Figure 7 This is a block diagram showing two SBCs and the conversation associated with the call forwarding when the media session associated with call forwarding resides on different SBCs;

[0045] Figure 8 This is a flowchart illustrating an exemplary process of call transfer to an answered target session by two SBCs, from the receipt of the transfer message to the sending of the re-invitation message; and

[0046] Figure 9 This is a flowchart illustrating an exemplary process from receiving a response to an invitation message to the call being transferred by two SBCs to a target session where someone answers the call. Detailed Implementation

[0047] This document describes methods, systems, and computer-readable media for answered call forwarding when multiple SBCs are involved and when a session with a forwarding target is reused. To illustrate the subject matter described herein, the original call is initiated by “A” to “B”, and “B” then forwards the call to “C”. In this case, “A” is the assignee, “B” is the transferor, and “C” is the forwarding target. Note that even if the forwarding is initiated by “A” instead of “B”, the proposed solution operates in the same manner, in which case the roles of “A” and “B” are interchanged. Furthermore, the terms “call” and “session” are used interchangeably. Additionally, the terms “transferor,” “assignee,” and “forwarding target” are intended to refer to the landline or mobile telecommunications equipment used by the end user to establish a media session and implement answered call forwarding. In the example described herein, answered call forwarding is performed between user equipment (UEs). Although the term UE is generally used to refer to a mobile device, the methods and systems described herein for inter-SBC call forwarding with target session reuse are applicable when any of the transferor, transferee, and transfer target is a landline VoIP phone.

[0048] A Service Controller (SBC) is a network element deployed in a VoIP network to monitor and control signaling and media streaming during Internet telephony calls. Because all signaling passes through the SBC, it inherently supports SIP call transfer procedures by transparently routing call-related signaling to / from the user agent. As will be described in detail below, existing SIP call transfer procedures involve a single SBC. However, when session routers are used to load balance sessions between SBCs, new sessions can log into different SBCs, and existing SIP call transfer procedures do not support answered call transfer with a target session reused without the modifications described herein.

[0049] Figure 1 This is a signaling message flowchart illustrating the exchange of exemplary SIP messages for call forwarding involving a single SBC. (Reference) Figure 1 UE A 100 initiates a call with UE B 102 via SBC 104. The call setup process begins on line 1, where UE A 100 sends a SIP invite message to SBC 104. SBC 104 identifies UE B 102 as the called party and sends a SIP invite message to UE B 102 on line 2. On line 3, UE B 102 sends a SIP 200 OK message to UE A 100 via SBC 104, and UE A 100 responds with an ACK message. After exchanging SIP 200 OK and ACK messages, a media session or call is established between UE A 100 and UE B 102 via SBC 104, as shown in line 4.

[0050] In line 5, UE B 102 initiates the establishment of a call with the transfer target by sending a SIP invitation message to SBC 104. SBC 104 identifies UE C 106 as the called party and sends a SIP invitation message to UE C 106 in line 6. In line 7, UE C 106 sends a SIP 200 OK message to UE B 102 via SBC 104. After line 7, a second session or call is established between UE B 102 and UE C 106 via SBC 104, as shown in line 8.

[0051] In line 9 of the message flow diagram, UE B 102 initiates a call transfer from UE A 100 to UE C 106 by sending a SIP transfer message to UE A 100 via SBC 104. In line 10, SBC 104 sends a SIP transfer message to UE A 100. In line 11, UE A 100 sends a SIP 202 message to UE B 102 via SBC 104. In line 12, SBC 104 sends a SIP 202 message to UE B 102.

[0052] In line 13 of the message flow diagram, UE A 100 initiates the process of establishing a media session with UE C 106 by sending a SIP invitation message to UE C 106 via SBC 104. In line 14, SBC 104 sends a SIP invitation message to UE C 106. The SIP invitation message includes a replacement header indicating that the media session between UE B 102 and UE C 106 should be replaced with a newly established media session between UE A 100 and UE C 106.

[0053] In line 15, SIP 200 OK and ACK messages are exchanged, and after line 15, a media session is established between UEA 100 and UE C 106 via SBC 104, as shown in line 16.

[0054] In lines 17 and 18, UE A 100 notifies UE B 102 of the transfer and releases the resources associated with the media session between UE A and UE B. In line 19, SBC 104 and UE C 106 signal to release the resources associated with the media session between UE B 102 and UE C 106.

[0055] Therefore, in Figure 1 In this context, a single SBC and SIP transfer method are used to perform call forwarding where someone is answering. Figure 1In this process, after receiving a SIP transfer message on line 10, UE A100 sends an invitation message to initiate the process of connecting the media session with the transfer target. In some cases, the SBC has sufficient intelligence to participate in call transfer, thereby optimizing the process by representing one or more parties in the call transfer.

[0056] For example, when the SBC receives a transfer from B in an AB session, the SBC can optionally generate an invitation to "C" on behalf of A. This allows the call to be transferred without having to proxy the transfer back to A. Upon successfully establishing a SIP conversation with C, the SBC internally replaces B with C in the existing AB session, thus connecting C to A without explicitly notifying A of the call transfer. After a successful transfer, the SBC can also optionally release the conversation toward B in the AB session. This applies to blind call transfer and answered call transfer, with associated signaling for answered call transfer cases such as... Figure 2 As shown.

[0057] refer to Figure 2 In lines 1-3, UE A 100 and UE B 102 exchange signaling messages via SBC 104 to establish a media session between UE A 100 and UE B 102. For example, in line 1, UE A 100 sends a SIP invitation message to SBC 104. SBC 104 identifies UE B 102 as the called party and sends a SIP invitation message to UE B 102 in line 2. In line 3, UE B 102 sends a SIP 200 OK message to UE A 100 via SBC 104, and UE A 100 responds with an ACK message. After exchanging the SIP 200 OK and ACK messages, as shown in line 4, a media session or call is established between UE A 100 and UE B 102 via SBC 104.

[0058] In lines 5-7, UE B 102 signals SBC 104 to establish a media session between UE B 102 and UE C 106 via SBC 104 for call forwarding if someone answers. In line 5, UE B 102 sends a SIP invitation message to SBC 104. SBC 104 identifies UE C 106 as the called party and sends a SIP invitation message to UE C 106 in line 6. In line 7, UE C 106 sends a SIP 200 OK message to UE B 102 via SBC 104. Following line 7, as shown in line 8, a second session or call is established between UE B 102 and UE C 106 via SBC 104.

[0059] In line 9 of the message flow diagram, UE B 102 sends a SIP transfer message to SBC 104, and in line 10, SBC 104 sends a SIP 202 accept message to UE B 102. This differs from... Figure 1 In the call flow, the transfer message is forwarded to UE A 100. In line 11, SBC 104 sends an invitation message on behalf of UE A 100 to UE C 106 to establish a media session between UE A 100 and UE C 106. In line 12, UE C 106 acknowledges the invitation message by sending a SIP200OK message to SBC 104, and SBC 104 responds with an ACK message. After the 200OK and ACK messages are exchanged in line 12, a media session is established between UE A 100 and UE C 106 via SBC 104, as shown in line 13.

[0060] In line 14, SBC 104 signals to UE B 102 to notify UE B 102 of the handover. In lines 15 and 16, UE B 102 terminates the call with UE A 100 and releases the associated media resources. In lines 17-19, UE C 106 signals to SBC 104 to release the resources associated with the media session between UE B 102 and UE C 106. Therefore, Figure 2 This illustrates a scenario where a call forwarding is performed using a single SBC, and the single SBC sends an invitation message on behalf of the transferee.

[0061] In another example of call forwarding where someone answers, the two calls involved in the forwarding (i.e., call AB and call BC) are established to the same SBC. The SBC can optionally send a re-invitation to C on the already established BC session to reuse the existing session, instead of sending a new invitation that would in turn create a new session. This is done to accommodate some user agents that do not support the replacement header in the invitation message. After the call forwarding, the SBC can also selectively release the call branch to B on both the AB and BC sessions. The method is as follows... Figure 3 As shown, this is called the re-invite method.

[0062] refer to Figure 3 Signaling in lines 1-4 Figure 1 and Figure 2 Similarly, the signaling and media in lines 5-8 establish a call between UE A 100 and UE B 102 via SBC 104.

[0063] Similar to Figure 2In lines 9-10, UE B 102 sends a transfer message to SBC 104 to transfer UE A 100 to UE C 106. In line 11, Figure 3 The signaling in the middle is different from Figure 2 Signaling within. In Figure 2 In line 11, SBC 104, on behalf of UE A 100, sends a new invitation to UE C 106 to initiate a new media session between UE A 100 and UE C 106. Figure 3 In line 11, SBC 104 sends a re-invitation to UE C 106 to reuse the resources of SBC 104 associated with the existing media session between UE B 102 and UE C 106.

[0064] exist Figure 3 In line 12, UE C 106 accepts the re-invitation by sending a SIP 200 OK message to SBC 104, and SBC 104 responds with an ACK message. Following line 12, a media session is established between UE A 100 and UE C 106 via SBC 104. The media session between UE A 100 and UE C 106 reuses the resources of SBC 104 previously used for the media session between UE B 102 and UE C 106.

[0065] Lines 14-16 and Figure 2 The corresponding signaling is the same in lines 17 and 18, where UE B 102 and SBC 104 signal to release resources associated with the media session between UE A 100 and UE B 102. In lines 17 and 18, SBC 104 signals to UE B 102 to release resources associated with the media session between UE B 102 and UE C 106. Therefore, Figure 3 This illustrates a scenario where a call is forwarded to an answered service using a single SBC, where the SBC employs a re-invitation method.

[0066] As long as both calls are associated with call forwarding or established through the same SBC. Figure 3 The re-invitation method shown works well. However, in some cases, the SBC set is deployed behind a session load balancer / router or session router (SR) used to distribute new incoming calls among the SBCs. This creates a problem for the scenario described above where AB calls and BC calls are established through different SBCs. In this case, if an SBC receives a transfer from B to C on the AB session, and the SBC does not host the BC session, the SBC cannot proceed with the re-invitation method. This is in... Figure 4As shown in the diagram. If this occurs, the SBC will typically revert to its standard behavior of sending an error response, transparently relaying the call to its intended recipient A, or sending a new invitation to C. In either of these cases, the media session between B and C cannot be reused because the SBC receiving the relay message is unaware of the relayed media session.

[0067] refer to Figure 4 In line 1, UE A 100 initiates a call with UE B 102 by sending an invitation message to session router (SR) 400. Session router 400 performs its load balancing algorithm and determines that the call should be sent to SBC 104. Therefore, in line 2, SR 400 sends an invitation message to SR 104.

[0068] In line 3, SBC 104 sends an invitation message to the called party, UE B 102. In line 4, UE B 102 sends a 200 OK message to UE A 100 via SBC 104, and UE A 100 responds with an ACK message. After line 4, a call or session is established between UE A 100 and UE B 102, as shown in line 5.

[0069] In line 6, UE B 102 initiates a call with UE C 106, which is the transfer target for call forwarding. This process is initiated by sending an invitation message to SR 400. SR 400 determines that the BC call should land on SBC 402, therefore, in line 7, SR 400 sends an invitation message to SBC 402, and in line 8, forwards the invitation message to UE C 106. In line 9, UE C 106 sends a 200 OK message to UE B 102 via SBC 402, and UE B 102 responds with an ACK message. After line 9, a media session is established between UE B 102 and UE C 106 via SBC 402, as shown in line 10. However, it should be noted that SBC 104 is unaware of this media session.

[0070] In line 11, UE B 102 sends a transfer message to SBC 104 to transfer the recipient to the transfer target (UEA 100 to UE C 106). The transfer message includes a replacement header for transferring A to C. Because SBC 104 is unaware of the BC call, in line 12, SBC 104 responds with a termination call transfer error message.

[0071] Since the SBC and SR are treated as a single unit, especially when all equipment is supplied by the same vendor, SBC users, such as network operators and enterprises, expect the re-invitation method to work even under load balancing conditions. The subject matter described in this article provides an optimized solution that facilitates a re-invitation method for call forwarding when two calls involved in a transfer are established through different SBCs located behind a session router in a load balancing session between SBCs.

[0072] The topics described here include a method for establishing a new call between two SBCs involved in two calls within an anchored call forwarding, and the exchange of custom information between SBCs to allow answered call forwarding using a re-invitation method. To perform answered call forwarding between SBCs using a re-invitation method, the SBC acts as a back-to-back user agent to manage the sessions involved in the call between the UE or user agent. The SBC maintains two conversations for each call or session, one with the calling party (internal conversation) and the other with the called party (external conversation). This is as follows: Figure 5 As shown. Reference Figure 5 SBC 104 maintains two sessions: Session 1 500 between UE A 100 and UE B 102, and Session 2 502 between UE B 102 and UE C 106. In Session 1 500, SBC 104 maintains an internal dialogue 504 with UE A 100 and an external dialogue 506 with UE B 102. Similarly, for Session 2 502, SBC 104 maintains an internal dialogue 508 with UE B 102 and an external dialogue 510 with UE C 106.

[0073] Figure 6 This is a message flow diagram illustrating call forwarding when someone answers using multiple SBCs and re-invitation methods. (Reference) Figure 6 In lines 1-4, UE A 100 signals to UE B 102 to establish a call between UE A 100 and UE B 102 via SBC 104. Following line 1, SR 400 selects SBC 104 for the first call. The corresponding call or media session is shown in line 5.

[0074] In lines 6-9, UE B 102 signals to UE C 106 to establish a media session or call between UE B 102 and UE C 106. In this example, as... Figure 4 As shown, SR 400 routes the second call to SBC 402. The second call or media session is shown in line 10.

[0075] In line 11 of the message flow diagram, UE B 102 sends a transfer message to SBC 104. The transfer message includes a replacement header for transferring A to C. When SBC 104 receives a transfer message from UE B 102 for a person-answered call transfer to C on the AB session, SBC 104 first attempts to find a matching in-session corresponding to the BC session using the session identifier from the replacement header in the transfer message. If SBC 104 does not find a matching session or conversation, SBC 104 sends a new invitation message to all SBCs in the same load-balanced or load-sharing group as SBC 104. The invitation message carries a custom header indicating that this is a special call used to trigger a person-answered call transfer to the BC session. The Session Description Protocol (SDP) portion of the invitation can be derived from the SDP portion of the invitation message received by SBC 104 for the AB session and may include SBC 104 media information such as IP address and port.

[0076] The presence of a custom header will instruct the receiving SBC to treat the invitation message as a special invitation and not route the call. If the SBC receiving the special invitation message does not host a call that matches the session ID in the replacement header, the SBC may send an error response message.

[0077] If the receiving SBC has an inner dialogue that matches the dialogue identifier in the replacement header, the SBC will initiate a re-invitation procedure to transfer A to C. The re-invitation will carry the same SDP information received from SBC 104.

[0078] Return to Figure 6 In the message flow of line 13, SBC 104 determines that it does not have an internal dialogue that matches the dialogue identified in the transfer message and sends an invitation message to all SBCs in the load-sharing group. SBC 402 is the only SBC that includes the internal dialogue that matches the dialogue in the replacement header of the invitation message. Therefore, in line 14, SBC 402 sends a re-invitation message to UE C106 to initiate the process of connecting the media session in line 10 or the external dialogue used for the media session to the internal dialogue of the media session with UE A in line 5. In line 15, UE C106 responds with a 200 OK (success) response message.

[0079] When a success response is received from UE C 106 in line 15 of the message flow diagram, SBC 402 replaces the intra-session of the BC session with an intra-session of the new session created between SBC 402 and 104 (hereinafter referred to as the S1-S2 session), and in line 16, sends a success response to SBC 104 to complete the establishment of the S1-S2 session, as well as the session description carried in the SDP portion of the 200OK message received from UE C 106 in line 15. The transparent exchange of the session description in the SDP portion of the 200OK message between SBC 104 and UE C 106 establishes a direct media path between SBC 104 and UE C 106, thereby optimizing media routing. The establishment of the S1-S2 session completes the media session between SBC 104 and 402, or via SBC 104 and 402, between UE A 100 and UE C 106, as shown in line 17.

[0080] Figure 7 This shows the conversation status during and after call forwarding. As mentioned in the previous paragraph, when in Figure 6 When a successful response is received from UE C 106 in line 15 of the message flow diagram, SBC 402 replaces the intra-dialogue of the BC session with the intra-dialogue of the S1-S2 session. Similarly, when a successful response is received from SBC 402 in line 16 of the message flow diagram, SBC 104 replaces the external dialogue in the AB call with the external dialogue from the S1-S2 call. SBC 104 then continues signaling exchange (i.e., notification and goodbye) with UE B 102 on the AB call in the same manner as when both calls are hosted on SBC 104. After establishing media path 700 between UE A 100 and UE C 106, SBC 104 signals to UE B 102 to remove or release resources associated with the external dialogue of the AB session. Similarly, once the intra-dialogue on the BC session is replaced with the intra-dialogue from the S1-S2 session, SBC 402 can release the resources associated with the intra-dialogue of the BC session.

[0081] Figure 8 and Figure 9 This is a flowchart illustrating an exemplary process performed by SBCs 104 and 402. When performing a call forwarding where someone answers, this occurs when the original call and the call associated with the forwarding target are established on separate SBCs. (Reference) Figure 8 This process begins when SBC104 receives a transfer message from UE B. The transfer message may include a replacement header, as mentioned above. Figure 6As described in line 11. SBC 104 extracts the conversation ID from the replacement header. In step 802, SBC 104 determines whether the conversation ID extracted from the replacement header is in the list of existing conversations being processed by SBC 104. If a conversation is found, it means that the call being transferred is being processed by SBC 104, and control proceeds to step 804, where transfer processing that does not involve inter-SBC calls is performed.

[0082] In step 802, if no dialogue from the replacement header is found in the existing dialogue list processed by SBC 104, control proceeds to step 806, where SBC 104 prepares a new invitation message with custom header information that identifies the invitation message as a request for call forwarding between SBCs.

[0083] In step 808, SBC 104 adds an SDP portion including the IP address and port of SBC 104 or Party A (the assignee in these examples) to the invitation message. In step 810, SBC 104 adds a custom header with the session ID extracted from the transfer message to the invitation message. In step 812, SBC 104 sends the invitation message to all SBCs in the same load-sharing group as SBC 104. The SBCs receiving the special invitation message perform a lookup in their respective session lists to determine if they are handling a session that exists in the replacement header of the invitation message. If the session ID is not in the list of session IDs being handled by the SBC, the SBC responds with a 4XX response. If the session ID from the replacement header of the special invitation message is found in the list of sessions being handled by the SBC, the receiving SBC signals the sending SBC to complete the call transfer.

[0084] SBC 402 receives the invitation message and determines in step 814 whether a custom header exists. If no custom header exists, control proceeds to step 815, where normal call processing is performed on the SBC to establish the session indicated by the invitation message. If a custom header is determined to exist in step 814, control proceeds to step 816, where SBC 402 extracts the session ID from the custom header.

[0085] In step 818, SBC 402 determines whether the conversation ID extracted from the replacement header exists in the conversation list being processed by SDP. If the conversation is not found, control proceeds to step 820, where SBC 402 sends a 4XX error response. If the conversation is found, control proceeds to step 822, where SBC 402 sends a re-invitation message carrying the SDP information received from SBC 104 to the transfer target.

[0086] refer to Figure 9 The process begins when SBC 402 receives a response from UE C106. In step 824, SBC 402 determines whether the response indicates success in accordance with a re-invite message. If the response does not indicate success, control proceeds to step 826, where SBC 402 sends a 4XX error response to SBC 104. In step 828, SBC 402 cleans up the call between S1 and S2 by releasing resources.

[0087] In step 824, if SBC 402 determines that a successful response has been received from the transfer target, control proceeds to step 832, where SBC 402 links the outer dialogue of the BC call with the inner dialogue of the S1-S2 call. In step 824, SBC 402 may optionally send a goodbye message to UE B 102 on the inner dialogue of the BC call to release resources. In step 834, SBC 402 sends a successful response to SBC 104 carrying the SDP information received from UE C 106.

[0088] Upon receiving a response to the special invitation message, in step 836, SBC 104 determines whether the response indicates success. If the response does not indicate success, control proceeds to step 838, where SBC 104 determines whether responses have been received from all SBCs in the load-sharing group.

[0089] If no response has been received from all SBCs, control proceeds to step 840, where SBC 104 waits for invitation responses from other SBCs in the load-sharing group. In step 838, if responses have been received from all SBCs and no response indicates success, control proceeds to step 842, where SBC 104 sends a notification message with a 4XX error code to UE B 102, indicating that the call transfer was unsuccessful.

[0090] In step 836, if the response to the special invitation message is successful, control proceeds to step 844, where SBC 104 links the external dialogue of the S1-S2 call with the internal dialogue of the AB call. Control then proceeds to step 846, where SBC 104 sends a notification message to UE B102 indicating a successful handover. In step 848, SBC 104 may optionally send a goodbye message to UE B102 on the external dialogue of the AB call to release the resources associated with that dialogue.

[0091] It will be understood that various details of the subject matter disclosed herein may be changed without departing from the scope of the subject matter. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes.

Claims

1. A method for optimized attended session border controller (SBC) to SBC call forwarding with transfer target session reuse, the method comprising: establishing, at a first SBC, a first media session between a donor and a recipient; establishing, at a second SBC, a second media session between the donor and a transfer target in response to a session initiation protocol (SIP) invite message initiated by the donor and routed to the second SBC by a session router; receiving, at the first SBC, a SIP REFER message initiated by the donor and including a dialog ID associated with the second media session, and in response, determining that the dialog ID does not correspond to a media session currently being handled by the first SBC, and sending a SIP invite message to a plurality of SBCs in a load sharing group with the first SBC including the second SBC, the SIP invite message including the dialog ID associated with the second media session; receiving, at the second SBC, the SIP invite message sent by the first SBC, identifying the SIP invite message sent by the first SBC as requesting an attended call forward to the transfer target, and in response, signaling the transfer target and the first SBC to reuse the second media session to establish a media session between the recipient and the transfer target, wherein signaling the first SBC and the transfer target to reuse the second media session to establish a media session between the recipient and the transfer target includes: sending a SIP re-INVITE message to the transfer target; receiving a success response from the transfer target; and in response to receiving the success response from the transfer target, sending a success response to the first SBC; establishing the media session between the first SBC and the second SBC; and replacing, at the first SBC, an outer dialog of the first media session with an outer dialog of the media session between the first SBC and the second SBC; and replacing, at the second SBC, an inner dialog of the second media session with an inner dialog of the media session between the first SBC and the second SBC.

2. The method of claim 1, wherein, establishing the first media session includes establishing the first media session in response to a SIP invite message initiated by the recipient and forwarded to the first SBC by the session router, the session router selecting the first SBC to handle the first media session using call distribution logic.

3. The method of claim 1 or claim 2, wherein, sending the SIP invite message initiated by the donor to the second SBC is based on call distribution logic of the session router.

4. The method of claim 1 or claim 2, wherein, receiving the SIP REFER message includes receiving the SIP REFER message with a replacement header including the dialog ID associated with the second media session.

5. The method of claim 1 or claim 2, wherein, sending the SIP invite message including the dialog ID associated with the second media session includes adding a custom header to the SIP invite message, the custom header indicating that the SIP invite message is to initiate an attended call forward that reuses the second media session.

6. The method of claim 1, comprising: sending a goodbye message to the donor at the first SBC and releasing resources associated with an outer dialog of the first media session.

7. The method of claim 1 or claim 6, comprising: sending a goodbye message to the donor at the second SBC and releasing resources associated with an inner dialog of the second media session.

8. A system for optimized attended session border controller (SBC) to SBC call forwarding with transfer target session reuse, the system comprising: a first SBC to establish a first media session between a donor and a recipient; and a second SBC to establish a second media session between the donor and a transfer target in response to a session initiation protocol (SIP) invite message initiated by the donor and routed to the second SBC by a session router; wherein the first SBC is configured to receive a SIP REFER message from the donor and including a dialog ID associated with the second media session, and in response, determine that the dialog ID does not correspond to a media session currently being handled by the first SBC, and send a SIP invite message to a plurality of SBCs including the second SBC in a load sharing group with the first SBC, the SIP invite message including the dialog ID associated with the second media session; and wherein the second SBC is configured to receive the SIP invite message sent by the first SBC, identify the SIP invite message sent by the first SBC as requesting an attended call forward to the transfer target, and in response, signal the transfer target and the first SBC to reuse the second media session to establish a media session between the recipient and the transfer target, wherein in signaling the first SBC and the transfer target to reuse the second media session to establish a media session between the recipient and the transfer target, the second SBC is configured to: send a SIP re-INVITE message to the transfer target; receive a success response from the transfer target; and in response to receiving the success response from the transfer target, send a success response to the first SBC; wherein the first SBC and the second SBC are configured to establish the media session between the first SBC and the second SBC; and wherein the first SBC is configured to replace an outer dialog of the first media session with an outer dialog of the media session between the first SBC and the second SBC, and the second SBC is configured to replace an inner dialog of the second media session with an inner dialog of the media session between the first SBC and the second SBC.

9. The system of claim 8, wherein, The first SBC is configured to establish the first media session in response to a SIP invite message initiated by the recipient and forwarded to the first SBC by the session router, the session router selecting the first SBC to handle the first media session using call assignment logic.

10. The system of claim 8 or claim 9, wherein, The SIP invite message initiated by the donor is sent to the second SBC based on call assignment logic of the session router.

11. The system of claim 8 or claim 9, wherein, The SIP REFER message includes a replacement header including the dialog ID associated with the second media session.

12. The system of claim 8 or claim 9, wherein, The first SBC is configured to include the dialog ID associated with the second media session in a custom header of the SIP invite message, wherein the custom header indicates that the SIP invite message is to initiate an attended call forward that reuses the second media session.

13. The system of claim 8, wherein, The first SBC is configured to send a SIP BYE message to the transferor and release resources associated with an outer dialog of the first media session and the second SBC is configured to send a SIP BYE message to the transferor and release resources associated with an inner dialog of the second media session.

14. A non-transitory computer readable medium having stored thereon executable instructions that, when executed by a processor of a computer, control the computer to perform steps comprising: establishing, at a first session border controller (SBC), a first media session between a transferor and a transferee; establishing, at a second SBC, a second media session between the transferor and a transfer target in response to a SIP INVITE message initiated by the transferor and routed to the second SBC by a session router; receiving, at the first SBC, a SIP REFER message initiated by the transferor and including a dialog ID associated with the second media session, and in response, determining that the dialog ID does not correspond to a media session currently being handled by the first SBC and sending a SIP INVITE message to a plurality of SBCs including the second SBC that are in a load sharing group with the first SBC, the SIP INVITE message sent by the first SBC including the dialog ID associated with the second media session; and receiving, at the second SBC, the SIP INVITE message sent by the first SBC, identifying the SIP INVITE message sent by the first SBC as requesting a call forwarding unconditional to the transfer target, and in response, signaling the transfer target and the first SBC to reuse the second media session to establish a media session between the transferee and the transfer target, wherein signaling the first SBC and the transfer target to reuse the second media session to establish a media session between the transferee and the transfer target includes: sending a SIP RE-INVITE message to the transfer target; receiving a success response from the transfer target; and sending a success response to the first SBC in response to receiving the success response from the transfer target; establishing a media session between the first SBC and the second SBC; and replacing, at the first SBC, an outer dialog of the first media session with an outer dialog of the media session between the first SBC and the second SBC; and replacing, at the second SBC, an inner dialog of the second media session with an inner dialog of the media session between the first SBC and the second SBC.

Citation Information

Patent Citations

  • Methods and apparatus for load balancing in SDN networks

    US20180077229A1

  • Mesh conferencing

    US9674242B1