Capability Grabbing Peer Device Functionality in SIP

BACKGROUND

Technical Field [001]The embodiments disclosed herein generally relate to Session Initiation protocol (SIP) functionality, and, more particularly, to a method for enhancing SIP functionality to integrate media capabilities of end terminals.

Description of the Related Art [002] There are many high-end phone terminals (Session Initiation Protocol

(SIP)/IP Media Subsystems (IMS) hardphones, softphones, cellular phones and so on) available in market. There exists no mechanism for a relatively unsophisticated terminal to have extra functions to be devolved to other capable terminals. For example, a calling terminal, terminal A with audio and video capabilities cannot perform the task of video exchange with the called terminal, terminal B which has audio capability but does not have video capability, and, in no way (at present), terminal B can devolve the task of video exchange to another video-capable terminal. Hence, it is not possible to aggregate media capabilities of various unsophisticated terminals and converse with high-end terminals. [003] The Session Initiation Protocol (SIP) exploits an application-level control protocol for setting up, changing and terminating multimedia sessions between participants on IP data networks. SIP can enable a range of services, such as Internet telephony, multimedia conferencing, registration and redirection services, simplifies

connecting to VPNs, etc.

[004] Generally, SIP functionality might not allow redirection of some particular type of media to other terminals. For instance, there can be two sessions at terminal A, one between A and B and the other between A and C. But present SIP terminal implementations treat the two sessions originating from terminal A as two different sessions. Thus, media sharing between two sessions is not possible and hence the sessions need to be switched i.e. one session at a time can only use the media I/O of the terminal.

[005] Session Description Protocol (SDP) negotiation is a solution put forward to address the problem of media sharing. Usually, SDP negotiation is implemented on behalf of a terminal (for example, terminal C) and this implementation requires prior knowledge of IP address of the terminal to which selected media need to be redirected. For example, if terminal B is assured that terminal C can handle SDP, then terminal B can respond to terminal A, including the SDP for terminal C. [006] However, the aforementioned method has the drawback of limiting the mobility of the user. A further drawback of the aforementioned method is that the IP address of an allocated terminal may change frequently. Also, it is not possible for multiple SIP terminals to receive the same media simultaneously. Furthermore, an application server infrastructure needs to be installed for signaling on behalf of a terminal.

SUMMARY [007] In view of the foregoing, an embodiment herein provides a method of

associating a session originating from a first terminal to a second terminal with the associated session originating from the first terminal to a third terminal, wherein the method comprises of initiating a session with the second terminal by the first terminal, accepting the session by the second terminal, second terminal sending a request to the first terminal for associating the session with the third terminal, first terminal accepting the request from the second terminal, first terminal initiating an associated session with the third terminal using an INVITE operation; and the associated session being accepted by the third terminal.

[008] In another embodiment disclosed herein, the second and third terminals have a single Address of Record (AoR).

[009] In another embodiment, a Session Initiation Protocol (SIP) REFER operation is used to associate the sessions, and the Content-Length and Content-Type of the REFER operation is as per IETF RFC 3515.

[0010] In another embodiment, the method uses a feature tag and a Call-ID field to associate the sessions and the feature tag is used with Refer-To header of the REFER message.

[0011] In another embodiment, the second terminal consults multiple associated terminals to learn the Session Description Protocol (SDP) of the associated terminals and selects the most optimum terminal as the third terminal. [0012] In another embodiment, the second terminal inserts Globally Routable

User Agent Uniform Resource Identification (GRUU) field of the third terminal in the request to point to the third terminal.

[0013] In yet another embodiment, Session Description Protocol Session (SDP) as

part of the body of the REFER method is used to convey delta SDP to be used for initiating dialog with third terminal.

[0014] In further embodiments, GRUU is inserted by the second terminal if GRUU is self-made, and the pre-stored GRUU is inserted by the second terminal if the GRUU is network generated or if the third terminal belongs to a different user.

[0015] Moreover, in another embodiment disclosed herein, the first terminal initiates the session with the third terminal automatically, or on reception of an indication from user of the first terminal. The indication from the user of the first terminal is in the form of a confirmation or assent. [0016] Moreover, in another embodiment disclosed herein, a terminal capable of associating a session originating from the terminal to a second terminal with a second session originating from the terminal to a third terminal, the terminal comprising of a means to read a feature tag and CALL-ID fields; a means to initiate an associated session with the third terminal on reading the feature tag and the CALL- ID fields; and a means to transfer media synchronously between the associated sessions.

[0017] These and other aspects of the embodiments disclosed herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments disclosed herein without departing from the spirit thereof, and the embodiments disclosed herein include all such modifications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The embodiments disclosed herein will be better understood from the following detailed description with reference to the drawings, in which: [0019] FIG. 1 is a block diagram illustrating the environment of the invention;

[0020] FIG. 2 illustrates a schematic diagram depicting SDP negotiation between user terminals;

[0021] FIG. 3 illustrates a flowchart depicting a method of basic CGPD implementation, according to the embodiments disclosed herein; [0022] FIG. 4 illustrates a flowchart depicting a method of Non-consultative

CGPD implementation, according to the embodiments disclosed herein;

[0023] FIG. 5 illustrates a flowchart depicting a method of receiving REFER message in CGPD implementation, according to the embodiments disclosed herein; and

[0024] FIG. 6 illustrates a flowchart depicting a method of implementing consultative CGPD, according to the embodiments disclosed herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0025] The embodiments disclosed herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments disclosed herein. The examples used herein are intended merely to facilitate an understanding of

ways in which the embodiments disclosed herein may be practiced and to further enable those of skill in the art to practice the embodiments disclosed herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments disclosed herein. [0026] The embodiments disclosed herein achieve a method to enhance the SIP functionality by providing a method to integrate media capabilities of the terminals. Referring now to the drawings, and more particularly to FIGS. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments. [0027] FIG. 1 is a block diagram 100 illustrating the environment of the invention. The first terminal 101 initiates a session with the second terminal 102 using a network 104. The network of first terminal and second terminal may belong to same network or different networks and network 104 may be an amalgamation of multiple networks. The second terminal 102 accepts the session and subsequently, sends a REFER request to first terminal 101 for associating the session with a third terminal 103. The first terminal 101 accepts the REFER request from the second terminal 102 and initiates an associated session with the third terminal 103 using an INVITE operation. The first terminal 101 uses delta SDP received in the REFER from second terminal 102 to negotiate with third terminal 103 and session between first terminal 101 and second terminal 102 continues in parallel with the associated session owing to REFER with the same cgpd tag and the same call-id of the session between first and second terminal.

[0028] FIG. 2 illustrates a schematic diagram 200 depicting SDP negotiation between user terminals. The first terminal 101 initiates a session with the second terminal

102 by sending an INVITE 203 with SDP to the second terminal 102 via Proxy -A 201 and Proxy- B 202. The second terminal 102 accepts the session and sends a 200-OK 204. The second terminal can then request the first terminal 101 to associate the session with another session between the first terminal 101, and a third terminal 103 either by pre- stored settings or by a user interaction. The user interaction can take the form of an indication, where the indication could be in the form of a confirmation or assent from the user. Further, the second terminal 102 sends a REFER 205 with Delta SDP as a request to the first terminal 101 to associate the session with the third terminal 103. The first terminal 101 accepts the request and sends the 202 Accepted response 206 with the selected delta SDP body. After successful selection of SDP body in the received REFER

206, the first terminal 101 sends an INVITE 207 with delta SDP through Proxy-C 209. The third terminal 103 accepts the associated session and sends a 200 OK 208 with the accepted-Delta SDP to the first terminal 101.

[0029] FIG. 3 illustrates a flowchart depicting a method of basic CGPD implementation, according to embodiments herein. The first terminal 101 initiates (301) a session with the second terminal 102. The second terminal 102 accepts (302) the session request from the first terminal 101 (by sending a 200-OK response), and subsequently sends (303) a REFER request with Delta SDP, with the same call id as the first session, and the cgpd tag to the first terminal 101 for associating the session with the third terminal 103. The first terminal 101 then initiates (304) a new session with the third terminal 103 using the Delta SDP of REFER. The third terminal 103 accepts (305) the session and the session between the first terminal and the second terminal continue (306) in parallel, with media being sent synchronously to the third terminal 103 also. The

various actions in method 300 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 3 may be omitted.

[0030] FIG. 4 illustrates a flowchart depicting a method of Non-consultative CGPD implementation, according to embodiments herein. The second terminal 102 indicates (401) delta SDP which may be the subset of media supported by first terminal in the body of REFER message and sets (402) 'cgpd' feature tag in Refer-To header. The second terminal 102 sets (403) call-id, which is the same as the existing session between the first terminal 101 and second terminal 102. A check is made (404) by the second terminal 102 to check if GRUU of the third terminal 103 (to which the capability is being devolved by the second terminal) is present in the memory of the second terminal 102. If GRUU is present in memory of the second terminal 102, then the pre-stored GRUU from the memory of second terminal 102 is inserted (405) in the Refer-To field of REFER message and the REFER message is sent (411) to the first terminal. If the GRUU is not present in the memory, then a further check (406) is made to check if the second terminal

102 and the third terminal 103 have the same AoR and is the GRUU self-generated. If the terminals are of same AoR and GRUU is self-generated, then the second terminal 102 generates and inserts (408) GRUU in the Refer-To field of REFER message and sends the REFER message (411) to the first terminal. If the terminals do not have the same AoR or if the GRUU is not self-generated (i.e., it is network generated), then the user at the second terminal 102 is prompted (407) to enter the GRUU of the third terminal. A further check is performed to check (409) if the user at second terminal entered the GRUU or not. If the user does not enter the GRUU, then REFER message is sent (410)

without the GRUU. If the user enters GRUU, then the second terminal 102 sends (411) the REFER message to the first terminal 101, where the REFER message contains the Refer-To field with the GRUU of the third terminal 103. The various actions in method 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 4 may be omitted.

[003I]FIG. 5 illustrates a flowchart depicting a method of receiving REFER message in CGPD implementation, according to embodiments herein. The first terminal 101 receives (501) REFER with delta SDP from the second terminal 102 and checks (502) if there is a match with media capability of first terminal 101. If SDP does not match with any of the media capabilities supported by the first terminal 101, the first terminal 101 sends (503) status code 417: Unsupported media streams to the second terminal 102 and the sharing of the media with the third terminal 103 will not occur. If the delta SDP matches with the media capabilities supported by the first terminal 101, the first terminal 101 sends (504) 202 Accepted with the selected SDP body to the second terminal 102. The SDP can match completely or partially with the media capabilities supported by the first terminal 101. First terminal 101 then initiates (505) the session with the third terminal 103 with the SDP selected from the received REFER. Further, REFER initiates (506) implicit subscription creation and notifications (as described in IETF RFC 3515). First terminal 101 then checks (507) if CALL-ID in the REFER message is same as the existing session dialog CALL-ID. If the CALL- ID is same, then a new session is associated (509) with the existing session and resources are shared between the sessions. If the CALL-ID is not same, then the new session is not associated (508) with the existing session. The various actions in method 500 may be performed in the order

presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.

[0032] FIG. 6 illustrates a flowchart depicting a method of implementing consultative CGPD, according to embodiments herein. Check (602) if the third terminal 103 and the second terminal 102 belong to two terminals of same AoR. If AoR is same, then REGISTER message is used (603) to retrieve the list of Contact URIs and corresponding GRUU attached to the AoR. If the AoR is not same, use (604) OPTIONS message to retrieve the list of contact URIs and corresponding GRUUs of the third terminal 103. The proxy returns a 3xx direction response in reply to the OPTIONS message sent by terminal 2, where the 3xx direction response comprises of the contact

URIs and the corresponding GRUUs of the third terminal. The first terminal 101 then sends (605) individual OPTIONS to all the contact URIs and retrieves the SDPs. Thereafter, the first terminal matches (606) the SDPs received in the response to the OPTIONS with the Delta SDP that the second terminal intends to send in the REFER and selects (607) optimum terminal from multiple terminals associated with third terminal

AoR. Further, the second terminal 102 sends (608) REFER message with the details of the selected optimum terminal in the Refer-To header and the delta SDP in the body of the REFER. The various actions in method 600 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 6 may be omitted.

[0033] In consultative CGPD, multiple terminals may be associated with the RERERed AoR, when the second terminal 102 inserts the AoR of the third terminal 103. For example, Home PC softphone, Office softphone and Mobile softphone can be

associated with same AoR. Sending REFER from the AoR implies CGPD assistance can be sought from any of the terminals. However, if Home PC softphone may have video capability but the mobile softphone may not have the same feature, then prior consultation of all terminals are required for correct functioning of CGPD. If CGPD is with same user, for instance, the third terminal 103 and the second terminal 102 belong to two terminals of same AoR i.e. the user is trying to devolve the responsibility of retrieving all the contact URIs and GRUUs to one of the terminals, REGISTER message can be used to retrieve the list of all the contact URIs and corresponding GRUUs attached to the AoR. The send terminal 102 then sends an OPTIONS message to each contact URFs to retrieve the SDP's. The OPTIONS request should contain the Accept header fields with "application/sdp" as these results in the response containing the SDP info. The SDPs are matched with delta SDP to find the most optimum contact URI for sending REFER message. If the user selects a particular terminal (AoR+ GRUU) then SDP matching may be used to determine that the third terminal 103 is capable of the required functionality. The Delta SDP information may also be conveyed in the feature tags as described in RFC 3840 and their use in REFER

[0034]If the third terminal 103 is not the same as the second terminal 102 then OPTIONS message handling at the proxy is required to be evolved and if the proxy determines that the AoR addressed in OPTIONS header posseses many bindings, then it should return 3xx redirection response including all the contact URIs and corresponding

GRUUs of the third terminal 103. The second terminal 102 then sends individual OPTIONS to all the contact URIs and retrieves the corresponding SDPs. The second terminal user agent matches the SDPs and finds out the optimum terminal before sending

the REFER message and also determines the capabilities of the selected terminal.

[0035] Embodiments herein also provide an SDP capability determination means prior to sending REFER message to a terminal where the SDP of the third terminal is analyzed and matched against the delta SDP to assure that the third terminal can take up the associated session. The user is also permitted to choose the most capable terminal from the list of terminals associated with a particular AoR. Embodiments herein can be implemented by the use of existing OPTIONS message capability to retrieve the SDP of any terminal. The OPTIONS request may include the Accept header field with "application/sdp" and the GRUU of the REFFERed terminal. The GRUU may be used to address all the bindings to the same AoR. Embodiments herein can be employed both for

Consultative CGPD with same user and with different user. The feature tags and the use of feature tags in REFER can be extended to convey the delta SDP information instead of transporting the delta SDP in the REFER message body as normal "application/sdp". The SDP capabilities in OPTIONS for consultative case can also be conveyed by use of extended feature tags in OPTIONS. It is obvious to a person skilled in the art that use of

GRUU as such is not mandatory in the embodiments herein, any means for the second terminal to be able to identify the third terminal unambiguously, and convey the information regarding the identified third terminal to the first terminal may be used.

[0036] Embodiments herein include standardization potential with CGPD functionality as the base of multiple killer applications and provide end users with unsophisticated terminals to enhance media transferring to other terminals. Embodiments herein also provide an easy approach to intervene application servers that can correlate the REFER message and subsequent INVITE and applying flexible user charging for the

service provider.

[0037] Embodiments herein also provide automatic SIP signaling to distinguish the third terminal. User mobility in Application Infrastructure Provider (AIP) network can be enabled by associating multiple terminals with same AoR and also provide an approach to receive the same media simultaneously by multiple SIP phones.

Embodiments herein do not involve any Back-To-Back-User Agent (B2BUA) or Application server infrastructure installation for signaling.

[0038] Embodiments herein provide extension for various services to evolve. For example, User A calls from a high-end phone that has capability to transmit video as well as audio. But the User B may not have the video capability and the user can press flash button and the number of a User C. As a result, the video can be exchanged between User A and User C while a voice session is going on between User A and User B. Also provide is a method for parallel recording of the video from User A though User B has video capability. Further, media services such as diversion of game playing to SIP softphones where high end rendering and graphics is possible due to higher processing power are provided.

[0039] As can be appreciated, the embodiments herein allow the use of SIP REFER operation for redirecting media to the third terminal by using REFER method with delta SDP in its body for conveying media synchronously to the third terminal and most importantly provides a basic infrastructure to enable numerous value added services.

[0040] Embodiments herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment including both

hardware and software elements. Embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc.

[0041] The list of structures corresponding to the claimed means is not exhaustive and that one skilled in the art understands that equivalent structures can be substituted for the recited structure without departing from the scope of the invention.

[0042]The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments disclosed herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments disclosed herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments disclosed herein can be practiced with modification within the spirit and scope of the appended claims.