KR101451478B1 - Sip transfer in a back-to-back user agent(b2bua) environment - Google Patents

Abstract

The system causes a change in the SIP INVITE message during the call transfer. Here, the user-associated element associated with the call may change the header information in the message to include the endpoint view of the diverting party. Thus, the INVITE message is sent back to the user-associated element of the divert party, which can interpret the received message and unbubble the B2BUAs in the real call path. The system affects the message change and includes changes in the user association element to interpret the received message once. Changes to user association elements eliminate the need to change communication endpoints.

Description

SIP TRANSFER IN A BACK-TO-BACK USER AGENT (B2BUA) ENVIRONMENT [0002]

The present invention relates to SIP switching in a back-to-back user agent environment.

In general, digital call systems allow users or system administrators to include applications in communication sessions. These applications can complete the traversed tasks, such as recording a call, obtaining information, providing caller information, and the like. In some communication systems, applications can be sequenced, which typically requires applications to be placed "back-to-back" in call topology. Accordingly, communications in the call are transmitted through each application in a sequence, including call data and management messages. In many cases, applications in a sequence are referred to as back-to-back user agents (B2BUAs).

Unfortunately, there are problems with using B2BUAs. In calls with more than two communication endpoints and during a call transfer, B2BUAs involved in a call transfer may disable the call transfer flows described in Request for Comments (RFC) 5589. Session Initiation Protocol (SIP) standards typically expect full visibility of dialog information from endpoints to endpoints. Many complex call attributes, such as call transfer, depend on the visibility of the dialog information. Unfortunately, B2BUA's impair call flows based on the assumption that dialogue information is visible. For example, B2BUAs may change the dialogue IDs and contact uniform resource identifiers (URIs) in a message prior to sending them to the next B2BUA or other system component. This action disables the Refer-To: URI / dialog ID by the switched endpoint.

While it is true that the far-end identity information is maintained in the request URI, To, P-asserted-identity, and From headers of the unique INVITE message, Headers are not enough to address a specific device. RFC 5589 dictates that conversions use the contact URI and the main dialog ID. Since this information is changed by B2BUAs, conversion is a problem.

Previous solutions have attempted to cause the primary B2BUA (sometimes referred to as call administrators) to block REFER and affect the conversion itself by re-INVITING the switched / target UAs so that they eventually communicate with each other. This leaves the sequenced B2BUAs for the party switching in the signaling path after the switching party drops from the call; It is not easy to recognize that a conversion has occurred with the unfortunate side effects of obscuring the conversion call flow from other sequenced B2BUAs.

Embodiments of the present disclosure have been considered for the above issues and other problems. In some embodiments, the system includes a change in an INVITE message during a switchover. Here, the user association element associated with the call may change the header information in the message to include the endpoint view of the party that is switching. Thus, the INVITE message can be interpreted as a user association element of the switching party that can interpret the received message and "unravel" the B2B UAs in the real call path (e.g., the call path established before the conversion is requested) It is sent again. The system affects the message change and includes a change in the user association element to interpret the received message once. Changes to user association elements eliminate the need to change endpoint UAs.

In embodiments, the system may include a proxy / registration / location server / attribute sequencer (referred to as a "user association element") to which a uniform resource identifier (URI) , Allowing standard UAs to participate in the call flow according to the standards defined in RFC 5589. The URI parameter in the contact URI ensures that the contact address captures the handle of the peer user even though the request traversed across B2BUAs. These parameters are then used by the user association element to properly sequence the B2BUAs in the INVITE-replace and to send the INVITE-replace to the constant-transfer target UA.

In particular, the user-associated element may implement one or more of the following rules: 1) upon receipt of a request or response from the UA, a unique identifier (address of record (AOR) -based global routable) UA URI (GRUU) or its equivalent], but it would not be necessary to generate AOR-GRUU if the endpoint contact URI is already an AOR-based GRUU; 2) generate an endpoint-view (epv) header comprising an AOR-based GRUU, a call-ID, and a local / remote tag; 3) Check whether the host part of the contact URI matches the registered contact for the user; 4) If there is a match (indicating that the request or response is being sent to the far-end UA), give information from the epv header to the epv parameter in the contact URI; And 5) complete these tasks in a stateless environment, with the exception of the already existing registered contact database.

Between the converting and not recognizing the converted UA, the Refer-To URI will then contain the epv parameter, which is also included as a URI parameter in the next INVITE-replace. The epv parameter is then used to correctly sequence the application during the transition (using INVITE-replace). The sequenced B2BUAs for the switching party can now be removed from the signaling path after the switching party drops the call. This is also much easier to recognize when a conversion occurs.

The term "user agent" or "UA" as used herein may refer to any hardware and / or software that runs a client application that implements functions or features in a communication session. The user agent may be one or multiple communication endpoints associated with or capable of establishing a communication session.

The term "user associated element" or "URE ", as used herein, refers to any hardware and / or software that generates on-demand access to services and applications, Applications, and infrastructure. The user association element may instantiate instances of applications to users that can be applied to UAs and to sessions from UAs. The user association element may perform tasks such as blocking calls based on user preferences, sending calls to users when they move across a company, and increasing caller ID information for incoming and outgoing calls And provides the ability to create profiles for third party users and add applications to be applied to users. In embodiments, the URE is an entity that initially sequences applications for preferences, such as user defined and / or administrative definitions, or preferences.

The term "call manager" as used herein may refer to any hardware and / or software, device, application, or infrastructure that is operable to assist in establishing communication sessions between two or more communication endpoints have. In embodiments, call manager is another B2BUA.

The term "globally routable UA URI (GRUU) " as used herein refers to any unique identifier (e.g., a URI) that can be used by any component of the system to route a call to a specific UA can do.

As used herein, the term "address of record (AOR)" may refer to any address that can be used to map or send a call to a specific user or system component. Thus, an AOR may be a "public address" of a user or component. A single AOR can be connected to multiple UAs. Generally, the AOR identifies the user and the GRUU identifies the device for that user.

The term "computer readable medium " as used herein refers to any type of storage device that participates in providing instructions to a processor for execution. Such media can take many forms including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, NVRAM, or magnetic or optical disks. Volatile media include dynamic memory, such as main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, a magnetic tape, any other magnetic medium, a magneto-optical medium, a CD-ROM, any other optical medium, a punch card, Solid state media such as EPROMs, FLASH-EPROMs, memory cards, any other memory chip or cartridge, or any other type of memory device that can be read by a computer Lt; RTI ID = 0.0 > media. ≪ / RTI > It should be appreciated that where the computer readable medium is configured as a database, the database may be any type of database, such as relational, hierarchical, and / or object oriented. Accordingly, embodiments are contemplated to encompass storage media of the type in which the software implementations of the present embodiments are stored, prior art recognized equivalents, and successor media.

The term "communication session" as used herein refers to any communication or set of communications between communication devices, including acoustic, video, text, or other multimedia data. Typically, a communication session includes two or more communication endpoints, UAs, and / or one or more communication servers (e.g., a SIP server).

The term "communication device" or "communication endpoint" as used herein refers to any hardware device and / or software operable to engage in a communication session. For example, the communication device may be an IP-enabled phone, a desktop phone, a cellular phone, a personal digital assistant, a soft-client telephone program running on a computer system, and so on. In an embodiment, the communication endpoint is a computer system as described in conjunction with Figs.

The term "Session Initiation Protocol" (SIP) as used herein refers to the widely used IEFT-defined signaling protocol for controlling multimedia communication sessions such as voice and video calls over the Internet Protocol (IP). A protocol may be used to create, modify, and terminate two-party (unicast) or multipart (multicast) sessions that consist of one or several media streams . Modification may involve changing addresses or ports, inviting more participants, and adding or deleting media streams. Other feasible application embodiments may include video conferencing, streaming multimedia distribution, instant messaging, information presence, file transmission, and online games. SIP is available from the Internet International Organization for Standardization (IETF) network working group, November 2000, as described in RFC 3261; The document and all other documents describing SIP are hereby incorporated by reference in their entirety for all of their teachings.

The term "network" as used herein refers to a system used by a communication platform to provide communications between communication endpoints. The network may be comprised of two or more users, voice or data, one or more user association elements that allow communications, feature servers, communication endpoints, and so on. The network may be any network or communication system as described in conjunction with FIGS. In general, a network may be a local area network (LAN), a wide area network (WAN), a wireless LAN, a wireless WAN, the Internet, etc., to receive and transmit messages or data between devices to facilitate communication platform activities. The network may communicate in any form or protocol known in the art, such as Transmission Control Protocol / Internet Protocol (TCP / IP), 802.11g, 802.11n, Bluetooth, or other forms or protocols.

The term "database", "archive", or "data structure" as used herein refers to any system, hardware, software, memory, storage device, firmware, component, . The data model may be any type of database or storage framework described in conjunction with FIGS. 6 and 7 stored in any type of non-transient, type computer readable medium. A database may include one or more data structures that may include one or more segments or portions that store items of data. The partition may include attributes of an object, a data field, or other types of partitions contained in one or more types of data structures, depending on the type of data structure. The data structure may represent a text string or may be a component of any type of database, such as relational databases, flat file databases, object-oriented databases, or other types of databases. In addition, data structures may be stored in memory structures or memory that may be used either in run-time applications or in initiating communications.

The phrases "at least one," " at least one, " and "and / or" are expressions that do not have limitations that are both connec- tive and indirect in function. At least one of A, B, and C, at least one of A, B, and C, at least one of A, B, and C, A and B together, A and B together, B and C together, or A, B and C together < RTI ID = 0.0 > it means.

The term " one "or" one "entity refers to one or more of the entities. Accordingly, the terms "one" (or "one"), "one or more", and "at least one" may be used interchangeably herein. It should also be noted that the terms "comprising "," comprising ", and "having" may be used interchangeably.

As used herein, the term "automatic" and variations thereof refer to any process or operation performed without the external force of the material person when the process or operation is performed. However, the process or operation may be automatic, provided that the external force is received prior to the execution of the process or operation, even though the performance of the process or operation utilizes the external force of the material or nonmaterial person. The external force of a person is considered to be material if such an external force affects how the process or operation is performed. The external force of a person who is consistent with the performance of a process or action is not considered "material".

As used herein, the terms "determining," " calculating, "and " computing, " and variations thereof are used interchangeably and include any type of methodology, process, mathematical operation or technique do.

The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or any combination of hardware and software capable of performing functionality associated with an element do. It should also be appreciated that while the various concepts are described in terms of exemplary embodiments, aspects may be claimed individually.

Hereinafter, "in communication ", as used herein, means that two or more systems, components, modules, devices, etc. are capable of exchanging data, signals, or other information using any protocol or format , ≪ / RTI > or wired.

The foregoing is a simplified summary in order to provide an understanding of some aspects of the embodiments. The above summary is not an extensive and complete overview of the various embodiments. This is not intended to identify key or critical elements and to delineate the scope of embodiments but is intended to provide the concepts selected in a simplified form as a prelude to the more detailed description that is provided below. As will be appreciated, other embodiments are possible utilizing one or more of the features described above or described in detail below, alone or in combination.

BRIEF DESCRIPTION OF THE DRAWINGS The present disclosure will be described in conjunction with the accompanying drawings.

Figures 1A-1C are block diagrams of embodiments of a system for switching communication sessions between UAs;
2 is a block diagram of an embodiment of a user associated element;
Figures 3A and 3B are logical block diagrams of embodiments of a data packet that may affect switching of a communication session;
Figures 4A and 4B are flow diagrams of an embodiment of a process for switching communication sessions between UAs;
5 is a block diagram of an embodiment of a computing environment;
6 is a block diagram of an embodiment of a computer.

In the accompanying drawings, similar components and / or features may have the same reference label. Also, various components of the same type can be distinguished by reference labels following letters that distinguish among similar components. If only a first reference label is used in the specification, the description is applicable to any one of similar components having the same first reference label regardless of the second reference label.

The following description merely provides embodiments and is not intended to limit the scope, applicability, or configuration of the embodiments. Rather, the following description will provide those skilled in the art with a description of what is possible to implement the embodiments. Various changes may be made in the function or arrangement of elements without departing from the spirit and scope of the embodiments as stated in the appended claims.

The call environment 100 is shown in Figures 1A-1C. The call environment 100 may include one or more components that communicate with each other. In embodiments, call environment 100 includes at least two UAs 102a, 102b, and / or 102c that communicate with each other during a communication session. A communication session may include a voice call, video call, or other exchange of real-time or near real-time communications in any type of media or combination of media. Communications sessions may all be implemented over any network 104 or system, such as a wide area network (WAN), a local area network (LAN), or other system, In embodiments, the communication session is implemented using digital transmissions, wherein at least some of the digital transmissions are control signals for executing or establishing a call. The control signals may be transmitted under one or more protocols, e.g., SIP.

The call environment 100 may include two or more UAs 102a, 102b, and / or 102c. When a communication session is created, the UAs 102a, 102b, and 102c may have applications included in the communication session according to their preferences. Applications may include specific call characteristics that are executed by B2BUAs 106 or 108 in the communication path between UAs 102a, 102b, and / or 102c. The applications may also include a call manager, which may provide functionality for establishing a communication session and for sequencing applications for inclusion in a communication session. The B2BUA 106/108 may be an application or software module operable to perform a function or characteristic for a user of the UA 102. For example, the B2BUA 106/108 may complete functions such as recording the media of the communication session, extracting metadata from the communication session, or other functions. The B2BUAs 106/108 are operable to be brought in or out in sequence and in-line by the communication path of the communication session. Thus, when a communication session is created, the user association element 110 may load or instantiate instances of the B2BUAs 106 and 108 in a sequence such that any communication data received from the other UA 102 is sent to that UA And transmitted or routed through B2BUAs 106/108. Thus, all B2BUAs 106/108 are in-line and back-to-back in the signaling path of the communication session.

The user association element 110 may be a software function that is executed by a processor on the server. In embodiments, the user association element 110 may include an Internet Protocol (IP) multimedia subsystem (IMS) serving-call session control function (S-CSCF) / smart common input Method (SCIM) function. The user association element 110 is operable to establish and implement communication sessions among one or more UAs 102 and one or more UAs 102. [ For example, user associated element 1 110a may establish and implement communication sessions for UA 1 102a. Similarly, user associated element 2 (110b) may establish and implement communication sessions for UA2 102b. In alternative embodiments, user associated element 1 (110a) and user associated element 2 (110b) are the same instance of user associated element (110) and are capable of conducting a communication session with both UAs (102). The user association element 110 is operable to control and implement communication sessions by establishing B2BUAs 106/108 and by connecting a sequence of B2BUAs 106/108 between the UAs 102 associated with the communication session

In FIG. 1A, UA 1 102a has established a communication session with UA 2 102b. Accordingly, B2BUA 1a 106a; B2BUA 2a 108a has been sequenced for UA 1 102a. As can be seen in FIG. 1A, B2BUAs are in-line and are connected in sequence between network 104 and UA 1 102a. Similarly, B2BUA 3a 106c; B2BUA 4a 108c is invoked and established in-line and in sequence for UA 2 102b by user associated element 2 (110b). The communication session shown in FIG. 1A represents a point-to-point communication session between UA 1 102a and UA 2 102b.

UA 1 102a may initiate the establishment of a first communication session with UA 2 102b, or UA 2 102b may be initiated UA, as shown in FIG. 1A. In FIG. 1B, UA 1 102a establishes a second communication session with UA 3 102c. Once again, one of UA 1 102a or UA 3 102c may match the starting UA. In the depicted embodiment, new instantiations of B2BUAs 108b and 106b are generated for UA 1 102a. Of course, it may also be possible to utilize B2BUA 1a 106a and / or B2BUA 2a 108a for the second communication session rather than involving the new B2BUAs 106b and 108b. It may also be possible that all of the UAs involved in any of the communication sessions described herein may be served by the same user association element 110 and possibly by the same B2B UAAs.

On the opposite side of the communication session, user associated element 3 110c establishes B2BUA 5a 106d and B2BUA 6a 108d for UA 3 102c. Thus, as shown in FIG. 1B, UA 1 102a is concurrently accompanied by two communication sessions, one by UA 2 102b and one by UA 3 102c.

Referring now to FIG. 1C, UA 1 102a has completed the transition, thereby establishing a third communication session between UA 2 102b and UA 3 102c. In a third communication session, UA 1 102a discontinues both the first and second communication sessions and a third communication session involving UA 2 102b and UA 3 102c causes the UAs to point to point and Direct communication. ≪ / RTI > The establishment of the third communication session may be completed in a number of ways. In the embodiment to be described below, the establishment of the third communication session is controlled by UA 1 102a acting as an entity to switch, UA 2 102b acting as an entity to be switched to, And is generated by the UA 3 102c acting as a target. However, it should be appreciated that UA2 102b may indeed be the target of the transition and UA3 102c may be the diverted entity. The steps and uniqueness of how these different communication sessions are established and how the entities are switched are discussed in conjunction with FIGS. 4A and 4B.

An embodiment of the user association element 110 is shown in Fig. The user association element 110 may be any type of hardware and / or software operable to establish and manage communication sessions to the UAs 102. In embodiments, the user association element 110 comprises one or more software modules. These software modules may include a GRUU insertion module 202, a GRUU interpretation module 204, an endpoint view insertion module 206, and / or an endpoint view interpretation module 208. The GRUU insertion module 202 is operable to insert a GRUU or AOR into a SIP message depending on certain triggers, such as the type of message or previous messages. For example, if the message is a switch from one sender to another, the GRUU insertion module 202 may insert a GRUU or AOR into the appropriate message to affect the switch of the call, as illustrated in FIG. 3A. Thus, the GRUU insertion module 202 is operable to modify SIP messages based on the type of message or other information.

The GRUU interpretation module 204 may issue commands to the GRUU insertion module 202 to interpret the type of message or other information and to modify one or more SIP messages. Thus, the GRUU interpretation module 204 can instruct the GRUU insertion module 202 to retrieve certain messages, e.g., SIP INVITE messages, and to change information in messages in the INVITE message or in subsequent messages have. The GRUU interpretation module 204 provides scanning capability to the user association element 110 to affect the call transfer as described in conjunction with FIGS. 4A and 4B.

In addition, the GRUU interpretation module 204 may receive INVITE messages, where the INVITE messages are for the UA 102 that is not associated with the local user association element 110. However, the INVITE message may be sent to the B2BUA 106, 108 via a communication path between the local UA and another UA. The GRUU interpretation module 204 may interpret these received INVITE messages to mean unbubbling the B2BUA. Accordingly, the GRUU interpretation module 204 provides the ability to unbind the user association element 110 to disassemble or unravel the communication path, as described in conjunction with FIGS. 4A and 4B.

The endpoint view (epv) insertion module 206 is operable to insert an AOR-based GRUU into the endpoint view header of any message, such as SIP messages. For example, if the message is a switch from one sender to another, the epv insert module 206 may insert an AOR-based GRUU in the appropriate message, as described in FIG. 3A. Thus, the epv insertion module 206 is operable to modify SIP messages based on the type of message or other information.

The epv interpretation module 208 may issue commands to the epv insertion module 206 to interpret the type of message or other information and to modify one or more SIP messages. Thus, the epv interpretation module 208 can instruct the epv insertion module 206 to retrieve certain messages, e.g., a SIP INVITE message, and to change information in the INVITE message, or in subsequent messages, have. The epv interpretation module 208 provides scanning capability to the user association element 110 to affect the call transfer as described in conjunction with Figures 4A and 4B.

Embodiments of the SIP message 300 are shown in Figures 3A and 3B, as used to implement other communication sessions in the call environment 100. SIP messages 300 may include one or more portions that may be fields or other message components. SIP message 300 may contain more or fewer fields than those shown in Figure 3A, as indicated by ellipses 314. In embodiments, portions of the message 300 may include a request-URI (R-URI) (which may be a URI identifying a remote end-point as a divert target and may also include a dialog identifier, a map-URI, (Which may include one or more of: a method, a target, an epv) 302, a to-field 304, a to-field 306, a call identifier field 308, a contact field 310, 312). These fields will be described in more detail below.

A first portion 302 of the SIP message 300 (hereinafter referred to as the R-URI field 302) may include a request line with a SIP method and a request-URI. The SIP method may include an INVITE command, a REFER message, an ACK message, or other types of SIP messages. The method represents the message type of many SIP messages and may include any other data needed for the command or message, such as to whom the command is to be sent. A 200 OK response message is also described herein. In embodiments, the INVITE-Replace message may include an endpoint-view (epv) parameter in the R-URI field 302 that provides the requestor URI with information about the party the message was targeted for . The R-URI field 302 of the message 300 is used by the GRUU interpretation module 302 to determine whether to adjust the invitee in the R-URI field 302 of its or other message, 204). An example of such a message is shown below:

As described above, &quot; INVITEsip: Called-User @ appW; The portion of the message containing epv = "<sip: Called-User @ Avaya; gr = 1234" is the R-URI field 302. As shown, the method is &quot; INVITE &quot;. The target is "Called-User @ appW". The epv parameter is "<sip: Called-User @ Avaya; gr = 1234>". The dialog identifier is &quot; Call-ID: AW &quot;. How these fields are used in communication processing is described in more detail with reference to Figures 4A-4B.

It should be noted that other embodiments of SIP messages as well as exemplary embodiments of the SIP messages herein show the ' epv ' parameter as being in double quotes. However, it is recognized that any type of SIP message format is possible without departing from the scope of the present disclosure. For example, for some SIP messages, the 'epv' parameter may be escaped using a hexadecimal number according to RFC 3261. The double quotes provided herein are used for discussion and for ease of readability of the message for illustrative purposes.

Field 304 may store information about the address for the message 300. [ The to-field 304 may include a name or address of a person or entity, or some other information identifying which entity 300 the message 300 is being sent to. Field 304 may include the address of the record for the destination of the message 300. In some embodiments, Similarly, the prompt field 306 may include information about the entity that transmitted the message 300. [ The prompt field 306 may include the address of the record or other information about the system or person that sent the message 300. [ The to-field 304 and the to-field 306 may also include tags that include a dialog identifier for communication with the call identifier in the to-field and / or prompt field.

The call identifier field 308, as the name suggests, may include information identifying one or both parties involved in the communication or devices used by the parties involved in the communication session. In some embodiments, the call identifier field 308 may include information about two or more parties that implement the communication session, or other information that uniquely identifies the call. In embodiments, call identifier 308 may include information that uniquely identifies a communication session for all other communication sessions. Thus, call identifier 308 may include a globally unique identifier (GUID) for the call or some other numbered, alphabetical, alphanumeric identifier.

The contact field 310 may include information describing a communication session. For example, the contact field 310 may include information about the type of transmission, port address, or other information associated with the communication session. The contact field 310 may be used to determine the identity of the transmitting device for the message.

The endpoint view field 312 is a newly added field to the embodiments described herein. The endpoint view field 312 may store information about the local view of the UA of the session. The endpoint view header 312 may include a unique identifier (e.g., an AOR-based GRUU or its equivalent) of the initial sender of the message, such information may be migrated to the epv parameter in the contact URI. 1B, the endpoint view field 312 is used to transport the GRUU of the endpoint 102a via the UA 102b (which is migrated to the epv parameter in the contact URI just before it is sent to the UA) ).

The information 316 for the epv field 312 is as shown in FIG. 3B. Epv information 316 may include more or fewer fields than those shown in FIG. 3B, as indicated by an ellipsis 324. The epv field 312 may include an AOR / GRUU 318, a local tag / remote tag 320, and / or a call identifier 322. The AOR / GRUU 318 may include information such as identification and addressing information for the UAs 102a / b / c. These UAs 102a / b / c may be included in one or more communication sessions. Thus, the AOR / GRUU 318 provides information about the transition that allows the call to be set up, as described in conjunction with FIGS. 4A-4C. The call identifier 322 may be the same as or similar to the call identifier 308 described with FIG. 3A. The local tag portion of the local tag / remote tag 320 may include a semi-random, semi-unique identifier generated by the local B2BUA for the specific session. The remote tag portion of the local tag / remote tag 320 may include a semi-random, semi-unique identifier generated by the remote B2BUA for the specific call. The epv field 312 may be used by the GRUU interpretation module 204 to identify when the entity specified in the command field 302 or in the command field 302 will be changed, The processor 202 may insert the AOR / GRUU from the epv field 312 into the to-field 304 or the command field 302.

The method for performing the call transfer is shown in FIGS. 4A and 4B. It should be appreciated that while the general sequence of steps of method 400 is shown in FIGS. 4A and 4B, the embodiments contemplate that the steps do not need to be performed accurately in the order in which they are described and depicted. Generally, the method 400 begins with the start operation and ends with the end operation. The method 400 may include more or fewer steps than the ones shown in FIGS. 4A and 4B and may arrange the order of the steps. The method 400 may be executed as a set of computer-executable instructions that are executed by a computer system and may be incoded or stored on a computer-readable medium. Hereinafter, the method 400 will be described with reference to the systems, components, modules, software, data structures, user interfaces,

UA 1 102a sends a SIP INVITE to user association element 1 110a to begin establishing a call with UA 2 102b at step 402. An example of an INVITE message can be viewed as follows (where &quot; Alice &quot; is UA 1 102a and &quot; Bob &

At this point, the authoritative user association element 110a for Alice may begin invoking or sequencing B2BUAs 106a and 108a. Thus, the user association element 110a initiates the B2BUA 1a 106a by sending an INVITE message (corresponding to the modified version of the unique INVITE message sent in step 402) to the B2BUA 1a 106a. An embodiment of the INVITE message sent from the user association element 1 (110a) to the B2BUA 1a (106a) may be modified to look as follows:

Here, the message is sent to B2BUA 1a 106a to invite UA 2 102b and the epv header is sent to Alice- "Endpoint-View: <sip: Alice @ Avaya; gr = 1234>; localtag = A; call-id = AW ". The epv header includes a GRUU for UA 1 102a and a dialog identifier &quot; call-id = AW &quot;.

B2BUA 1a 106a returns an INVITE message to user associated element 1 (110a). Thereafter, if additional applications need to be sequenced on behalf of Alice, user associated element 1 110a sends an INVITE message to these additional applications (e.g., B2BUA 2a 108a). After B2BUA 2a 108a processes the INVITE message and executes its designated functions, B2BUA 2a 108a returns an INVITE message to user associated element 1 110a. Upon receipt of the INVITE message from B2BUA 2a 108a, user associated element 1 110a may determine that no additional applications need to be sequenced for Alice, and based on the determination, Lt; RTI ID = 0.0 &gt; 110b &lt; / RTI &gt;

User association element 2 110b sequences B2BUAs 106c / 108c for a user (e.g., Bob) associated with UA2 102b. The manner and order in which applications are sequenced may depend on the preference defined by Bob or by default / manager preferences. In some embodiments, user associated element 2 110b sends an INVITE message to B2BUA 3a 106c, receives an INVITE message back from B2BUA 3a 106c, and then sends an INVITE message to B2BUA 4a 108c To sequence the B2BUA 3a 106c. After the B2BUA 4a 108c completes processing the INVITE message, the user associated element 2 110b receives the INVITE message back from the B2BUA 4a 108c and then at step 406, the UA [ (E.g., UA 2 102b).

An example INVITE message sent to UA 2 102b may be represented as:

Here, &quot; AppX &quot; may be the last B2BUA 4a 108c in the set of sequenced applications for the incoming party (e.g., Bob). It should be noted that the epv header has been maintained throughout the time sequenced by the user association elements 110, and the information contained in the epv header is transmitted to UA2 102b. However, prior to providing an INVITE to UA 2 102b, user associated element 2 110b may insert the information that was maintained in the epv header during message routing as a parameter in the contact URI of the INVITE message. Thus, the user association element 110 may modify the contact URI, call-ID, to-and-forward tags, while maintaining the epv header originally created by the user-associated element 1 110a.

UA 2 102b may, in step 408, accept the receipt of the INVITE request by sending a 200 OK message to user associated element 2 100b. User association element 2 110b routes the 200 OK message through B2BUA 4a 108c and B2BUA 3a 106c and then transfers it to user association element 1 110a at step 410. [ An example of a response message may appear as follows:

Here, the endpoint view of UA 2 102b is included in the epv header, which may remain unaltered through sequencing and transfer to UA 1 102a.

User association element 1 110a routes the 200 OK message through B2BUA 2a 108a and B2BUA 1a 106a. Eventually, the user association element 1 110a receives the 200 OK message and sends a 200 OK message to the UA 1 102a in step 412. In embodiments, the epv parameter is inserted by user associated element 1 (110a) into the contact header of the 200 OK message prior to providing the message to UA 1 102a. A series of SIP ACK messages may then be sent from UA 1 102a to UA 2 102b in the same manner as SIP INVITE messages. At this point, as shown in Figure 1A, a first communication session is created between UA1 102a and UA2 102b.

At some point thereafter, the user of UA 1 102a (e.g., Alice) may determine to switch UA 2 102b to UA 3 102c. This may occur after Alice receives a call from a user of UA 3 102c (e.g., &quot; Carol &quot;) or Alice initiates a call to a user of UA 3 102c. To complete the switch, UA 1 102a softly holds UA 2 102b. The routing of the hold message from UA 1 102a to UA 2 102b is performed by the above described INVITE message / 200 OK message in which the hold message follows the contact / record-route headers as an in- Follow the same procedure as for the / ACK message. The routing of the hold message will not be described below. While the first communication session is suspended, UA 1 102a establishes a new communication session (e.g., a second communication session) with UA 3 102c. The second communication session may be initiated by Alice or Carol. An embodiment of a message for establishing a second communication session initiated by Alice may be represented as follows:

Accordingly, user association elements 110a and 110c execute or instantiate B2BUAs 106b, 108b, 106d, and 108d. The procedure for establishing the second communication session involves transmitting an INVITE message from UA 1 102a to user association element 1 110a at step 414. [ The user association element 1 110a then sequences the B2BUAs 106b and 108b. The user association element 1 110a then sends an INVITE message to the user association element 3 110c at step 416. In response to receiving the INVITE message, user-associated element 3 110c may be associated with a user (e.g., Carol) of UA 3 102c or by an application that sequences limited preferences for a user of UA 3 102c The B2BUAs 106d and 108d may be sequenced. Once the appropriate applications have been sequenced once as B2BUAs, an INVITE message is sent, at step 418, from user-associated element 3 110c to UA 3 102c. An example of an INVITE message sent to UA 3 102c may be represented as follows:

As can be seen from the example message, the epv parameter contains information about the endpoint view for UA 1 102a. UA 3 102c then sends a 200 OK message back to user associated element 3 110c at step 420. The user association element 3 110c then routes the 200 OK message through the B2BUAs 108d and 106d and sends it to the user association element 1 110a at step 422. [ At step 424, user associated element 1 110a then sends a 200 OK message, along with the epv parameter, to UA 1 102a via B2BUAs 108b and 106b. A series of SIP ACK messages are then sent in a similar manner from UA 1 102a to user association element 1 110a, then to user association element 3 110c, and then to UA 3 102c Lt; / RTI &gt; At this time, a second communication session is established. After establishing the second communication session, the configuration of the communication environment 100 is as shown in FIG. 1B. Hereinafter, UA 1 (102a) can send a REFER message that will affect the conversion of Bob to Carol.

The divert process starts when UA 1 102a sends a REFER message destined for UA 2 102b. The REFER message is first sent to the user association element 1 (110a) at step 426. An embodiment of the REFER message may be represented as follows:

The REFER message may be the same as the messages shown in FIGS. 3A and 3B. The REFER message includes a REFER-To header including an epv parameter that provides information about the conversion target (e.g., UA 3 102c), e.g., "Refer-To: Carol <sip: AppY @ appyIP; epv = "<sip: Carol @ Avaya; gr = 9012>; localtag = C; remotetag = Z; call-id = ZC "; Replaces = AW &quot;, &quot;. This information is kept in the REFER message until the REFER message reaches the destination of the message.

The user association elements 1 and 2 (110a and 110b) are connected via all sequenced B2BUAs (106/108) associated with the first communication session to notify those that the call structure changes from what is shown in FIG. 1B to what is shown in FIG. 1C. Send a REFER message. User associated element 1 110a routes this REFER message in step 428 through B2BUA 1a 106a, B2BUA 2a 108a and to user associated element 2 110b. User association element 2 110b sends a REFER message to B2BUA 3a 106c, B2BUA 4a 108c and then to UA 2 102b at step 430. The REFER message received by UA 2 102b may be represented as:

In order to engage UA3 102c in the third communication session, UA2 102b sends an INVITE message with a replacement identifier including a dialog identifier, e.g., &quot; Replaces = AY &quot; from the Refer-To header. An example of an INVITE message sent by UA 2 102b may be represented as:

The request URI in the INVITE message is targeted at B2BUA 1b 106b, e.g., "sip: AppY @ appyIP", but the epv parameter is the AOR / GRUU of UA 3 (102c) ; gr = 9012>; localtag = C; remotetag = Z; call-id = ZC ">". Thus, the INVITE message will typically resend the communication session via B2BUA 1b (106b) because it is the URI of B2BUA 1b (106b) very close to UA 1 (102a). However, in these embodiments, an INVITE message is sent from UA 2 102b to user-associated element 2 110b at step 432. When the user association element 2 (110b) receives such an INVITE message, the user associated element 2 (110b) completes several steps before or during the entry processing of the origin processing of the INVITE message. First, the user association element 2 (110b) judges whether the epv information is present in the INVITE message. If there is real epv information, user associated element 2 (110b) stores the current R-URI in the &quot; map-URI &quot; header or parameter. In addition, user-associated element 2 (110b) uses the AOR / GRUU from the epv of the INVITE message, so that the applications understand who the INVITE message is directed to. An example of a message generated during such processing is as follows:

Here, if the user association element 2 (110b) is the &quot; map-URI = appy @ appyIP; SIP / 2.0> "and migrate the R-URI with the AOR / GRUU (Carol @ Avaya; gr = 9012) from the epv header. User associated element 2 110b then initiates the originating applications B2BUA 3b 106e and B2BUA 4b 108e for this communication path, which may be different from the terminating applications 106c and 108c.

User-associated element 2 (110b) may then re-store the R-URI from the map-URI field. User association element 2 110b sends a new modified INVITE message to user association element 1 110a at step 434 to initiate the unraveling process of the embodiment shown below:

The user association element 1 (110a) now sends an INVITE message via B2BUA 1b (106b) and B2BUA 2b (108b) for unbinding. During unbubbing, B2BUAs 106b and 108b use the dialogue ID to look up the replacement dialogue ID and map the R-URI and the replacement dialogue ID to be their &quot; next-door neighbor &quot;. For example, after the B2BUA 106b has unpacked the INVITE, it can be represented as shown below:

After unbuffling the B2BUA 1b 106b and the B2BUA 2b 108b, the user association element 1 110a may transmit the INVITE to the user association element 3 110c in step 440. In response to receiving the INVITE message, user associated element 3 110c may then unblaze B2BUA 5a 106d and B2BUA 6a 108d. The user association elements 110 may also determine when to stop the unbubbing process. Each user association element 110 may compare the R-URI with the contact URI registered for the user's device (s) in the epv header. Thus, if user-associated element 3 110c finds a match for UA 3 102c, then user-associated element 3 110c may then perform term sequencing (e.g., application sequencing ).

When moving from unleaved to term sequencing, user associated element 3 (110c) may perform some URI mapping. If UA 3 102c does not detect the GRUU, the contact URI of UA 3 102c (which is now the R-URI) can not have an AOR in it. Thus, user-associated element 3 110c may again store the R-URI in the map-URI header or parameter, promote the URI from the epv parameter, and initiate term sequencing. An example message for this process is shown below:

At this point, user-associated element 3 110c will sequence the INVITE via B2BUA 5b 106f and B2BUA 6b 108f, which may be different from end applications 106d and 108d.

When the user association element 3 (110c) completes this process, it will re-store the unique R-URI and finally send a message to UA 3 102c. In this process, user-associated element 3 110c may resubmit the unique R-URI from the map-URI and then send an INVITE message to UA 3 102c at step 442, At 444, a 200 OK message may be sent back to user associated element 3 110c. The user association element 3 110c may route the 200 OK message at step 446 to the B2BUA 6b 108f, the B2BUA 5b 106f and then to the user association element 2 110b. At step 448, user associated element 2 110b then routes the 200 OK message to B2BUA 4b 108e and B2BUA 3b 106e and then finally to UA2 102b. While receiving the 200 OK message, the UA 2 102b accepts the reception at step 448 by an ACK message that is routed back to the UA 3 102c in a manner contrary to the routing of the 200 OK message.

After routing the 200 OK message and any ACK messages, the call structure may be represented as in FIG. 1C. Thus, after the INVITE-Replace is complete, the UA 3 102c will send a BYE message to the UA 1 102a, which will cause the B2BUAs 106/108 sequenced in the communication path established for the second communication session Quot;). UA2 102b may also send a sip-frag NOTIFY message back to UA1 102a while continuing to inform UA1 102a of the state of the INVITE-Replace. Once the UA 1 102a recognizes that a new dialog has been established, the UA 1 102a will receive the UA 2 102a / 102b, which can clear all of the B2BUAs 106/108 between these two UAs 102a / 0.0 &gt; 102b. &Lt; / RTI &gt; Existing changes provide the advantage of reducing the amount of processing that is required to handle calls after a switch, as unneeded B2BUAs are not in sequence with parties in the switched call. This transition can be done with one or more people as it is routed through several branches of the call environment to disassemble or unbroadcast the parties of the converted call.

FIG. 5 illustrates a block diagram of a computing environment 500 on which systems, devices, servers, software modules, etc. may execute. Accordingly, the system or components described in conjunction with FIG. 5 may be commodity hardware. The computing environment 500 includes one or more user computers 505, 510, and 515. The user computers 505, 510, and 515 may be general purpose personal computers (personal computers running various versions of Macintosh &lt; (R) &gt; And / or laptop computers) and / or workstation computers running any of a variety of commercially available UNIX (TM) or UNIX-like operating systems. These user computers 505, 510, 515 may also have any of a variety of applications including, for example, database clients and / or server applications, and web browser applications. Alternatively, the user computers 505, 510, and 515 may communicate via a network (e.g., network 520, described below) and / or display web pages or other types of electronic documents, Such as a thin-client computer, an Internet-enabled mobile phone, and / or a personal digital assistant, which may be connected to the Internet. While a typical computing environment 500 is represented by three user computers, any number of user computers may be supported.

The computing environment 500 also includes a network 520. Network 520 may be any type of network familiar to those skilled in the art that is capable of supporting data communications using any of a variety of commercially available protocols including, without limitation, SIP, TCP / IP, SNA, IPX, AppleTalk, . By way of example only, network 520 may include a local area network ("LAN") such as an Ethernet network, a Token-Ring network, etc.; Wide area network; A virtual network that includes without limitation a virtual private network ("VPN"); Internet; Intranet; Extranet; Public Switched Telephone Network ("PSTN"); Infrared network; A wireless network (e.g., any IEEE 502.11 suite of protocols, a Bluetooth ™ protocol known in the art, and / or a network operating under any other wireless protocol); And / or any combination of these and / or other networks. The network 520 may be the same as or similar to the network 104.

The system may also include one or more server computers 525, 530. One server may be a web server 525, which may be used to process requests for web pages or other electronic documents from the user computers 505, 510, and 515. The web server may be running commercially available server operating systems as well as operating systems including any of those discussed above. Web server 525 may also execute various server applications including SIP servers, HTTP servers, FTP servers, CGI servers, database servers, Java servers, In some cases, the web server 525 may publish operations available as one or more web services.

The computing environment 500 may also include one or more files and / or applications in the server 530, which may include, in addition to the operating system, a client running on one or more user computers 505, 510, Lt; RTI ID = 0.0 &gt; and / or &lt; / RTI &gt; The server (s) 530 may be one or more general purpose computers capable of executing programs and scripts in response to the user computers 505, 510, and 515. As an example, a server may execute one or more web applications. The web application may be any programming language such as Java, C, C #, or C ++, and / or any scripting language such as Perl, Python, or TCL, as well as any one written in any combination of programming / The above may be implemented as scripts or programs. The application server (s) 530 may also include database servers that include, without limitation, those commercially available from Oracle, Microsoft, Sybase ™, IBM ™, etc., Lt; / RTI &gt;

The web pages generated by the web application server 530 may be sent to the user computer 505 via the web server 525. [ Similarly, web server 525 may receive web page requests, web service calls, and / or input data from user computer 505 and provide web page requests and / or input data . In further embodiments, the server 530 may function as a file server. 5 illustrates a separate web server 525 and file / application server 530, those skilled in the art will appreciate that the functions described with respect to servers 525 and 530 may be implemented using implementation-specific requirements and parameters May be performed by a single server and / or by a plurality of specialized servers.

The computing environment 500 may also include a database 535 or multiple databases. The database 535 may reside in various locations. By way of example, database 535 may reside on a storage medium that is near (and / or resident) one or more computers 505, 510, 515, 525, Alternatively, it may be remote from any or all of the computers 505, 510, 515, 525, 530 and may communicate with one or more of them (e.g., via network 520). For a particular set of embodiments, the database 535 may reside in a storage-area network ("SAN") that is familiar to those skilled in the art. Likewise, any necessary files for performing the functions attributed to the computers 505, 510, 515, 525, 530 may be stored near and / or remotely to each computer, as appropriate. In one set of embodiments, the database 535 may be a relational database, such as Oracle 10i ™, adapted to store, update, and recover data in response to SQL-formatted commands.

FIG. 6 illustrates one embodiment of a computer system 600 in which the systems, devices, servers, software modules, and so on described herein may be deployed or executed. Computer system 600 is shown as having hardware components that can be electrically connected via bus 655. [ The hardware components include one or more central processing units (CPUs) 605; One or more input devices 610 (e.g., a mouse, keyboard, etc.); And one or more output devices 615 (e.g., a display device, printer, etc.). Computer system 600 may also include one or more storage devices 620. By way of example, the storage device (s) 620 may be a solid-state storage device such as disk drives, optical storage devices, random access memory ("RAM"), and / Devices, which may be programmable and / or flash-update enabled and / or the like.

Computer system 600 includes a computer-readable storage medium reader 625; A communication system 630 (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.); And a working memory 640, which may include RAM and ROM devices as described above. In some embodiments, the computer system 600 may also include a processing acceleration unit 635, which may include a DSP, a special-purpose processor, or the like.

The computer-readable storage medium reader 625 may also include a storage medium in addition to the storage medium in remote, near, fixed, and / or removable storage devices to temporarily and / or more permanently store computer- (And, optionally, in combination with storage device (s) 620) to a computer-readable storage medium that generically represents the storage medium The communication system 630 may allow data to be exchanged with the network and / or any other computer described above with respect to the computer system 600. Also, as disclosed herein, the term "storage medium" refers to a storage medium such as read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage media, Memory devices and / or other machine-readable media for storing information.

The computer system 600 may also include software components that are currently located within the working memory 640 that includes an operating system 645 and / or other code (code) It should be appreciated that alternative embodiments of computer system 600 may have many variations from the above. For example, customized hardware may also be utilized and / or certain elements may be implemented in hardware, software (including portable software such as applets), or both. Also, connections to other computing devices such as network input / output devices may be employed.

In the foregoing description, for purposes of illustration, the methods have been described in a particular order. It should be appreciated that, in alternate embodiments, the methods may be performed in a different order than described. The methods described above may be performed by hardware components or may be implemented in a machine-executable system that may be used to cause machines, such as logic circuits programmed with instructions to perform general-purpose or special-purpose processors or methods It should also be appreciated that sequences of instructions may be implicit. These machine-executable instructions may be stored on CD-ROMs or other types of optical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, Or other types of machine-readable media suitable for use with a computer-readable medium. Alternatively, the methods may be performed by a combination of hardware and software.

Specific details have been set forth in order to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments with unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

It is also noted that the embodiments have been described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although flowcharts can describe operations as sequential processes, many operations can be performed in parallel or concurrently. Also, the order of operations can be rearranged. The process terminates when the operations are completed, but may have additional steps not included in the figures. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and so on. If the process matches the function, its termination corresponds to the return of the function to the calling function or main function.

Further, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the required tasks may be stored in a machine-readable medium, such as a storage medium. The processor (s) may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program segments. A code segment may be connected to another code segment or hardware circuit by passing and / or receiving information, data, independent variables, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, sent, or transmitted through any suitable means including memory sharing, message passing, token passing, network transmission,

Although the exemplary embodiments have been described in detail herein, it is to be understood that the concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be understood as including the modifications, except as defined by the prior art Should be understood.

Claims (10)

A method for enabling a user agent (UA) associated with a first communication session to switch to another communication session,
The method comprising: receiving the first message including a unique identifier inserted into at least one portion of a first message, the at least one portion including at least one of a header and a parameter of the first message; Traverses at least one back-to-back UA (B2BUA)
Extracting the unique identifier from the at least one portion of the first message;
And inserting the extracted unique identifier into a Uniform Resource Identifier (URI) of the first message
Way.
The method according to claim 1,
Wherein the unique identifier comprises an globally routable UA URI (GRUU) identifying an endpoint associated with the first communication session and an address of record (AOR) of the user of the first communication device Wherein the at least one portion of the first message comprises one or more endpoint view headers or endpoint view parameters
Way.
The method according to claim 1,
Receiving a second message corresponding to an out-of-dialog INVITE-Replaces message;
Determining that the second message includes endpoint view information embedded in a request-URI (R-URI) of the second message;
Promoting the unique identifier to be the primary URI in the R-URI of the second message
Way.
The method of claim 3,
Storing the original R-URI value in a place-holding header or parameter of the second message before promoting the unique identifier to be the primary URI of the second message; ,
Using the unique identifier to route the second message and sequence originating applications for the other communication session;
Further comprising restoring the original R-URI value from the batch-maintain header or parameter back to the primary R-URI of the second message after the originating applications are sequenced for the other communication session
Way.
5. The method of claim 4,
Receiving the second message after the originating applications are sequenced for the other communication session;
Further comprising unraveling each sequenced application for the first communication session,
Wherein unpacking each of the applications further comprises causing each application, sequenced for the first communication session, to remove itself from the communication path of the other communication session
Way.
6. The method of claim 5,
Wherein each application sequenced for the first communication session transmits the second message without performing a write route function and each application sequenced for the first communication session sends the second message The R-URI and the replacement header of the second message are modified using a dialog map before proxying
Way.
6. The method of claim 5,
Wherein each application sequenced for the first communication session compares the R-URI of the second message with a registered contact URI for devices associated with the unique identifier
Way.
5. The method of claim 4,
Receiving the second message after the originating applications are sequenced for the other communication session;
Further comprising directing the second message to a user relation element associated with the conversion target
Way.
A server configured to facilitate switching from a first communication session of a user agent (UA) to another communication session,
A user associated element configured to be executed by the processor and configured to receive a first message during the first communication session or during the establishment of the first communication session, the first message comprising at least one back- (B2BUA), the user association element further extracting a unique identifier from a portion of the first message and inserting the extracted unique identifier into a contact uniform resource identifier (URI) of the first message
server.
10. The method of claim 9,
Wherein the unique identifier is extracted from at least one of a header and a parameter of the first message, the unique identifier comprises a globally routable UA URI (GRUU), the first message is an INVITE message, (AOR) of the first UA that transmitted the first UA and the record of the user of the first UA,
The user association element is further configured to receive a 200 OK response to the INVITE message, extract a second unique identifier from the 200 OK response, and insert the extracted second unique identifier into the contact URI of the 200 OK response ,
Wherein the second unique identifier comprises a GRUU that identifies an AOR for a user of the second UA as well as a second UA that has received the INVITE message and sent the 200 OK response
server.

Images