WO2008004962A2 - Reduced memory usage between communication servers - Google Patents
Reduced memory usage between communication servers Download PDFInfo
- Publication number
- WO2008004962A2 WO2008004962A2 PCT/SE2007/050283 SE2007050283W WO2008004962A2 WO 2008004962 A2 WO2008004962 A2 WO 2008004962A2 SE 2007050283 W SE2007050283 W SE 2007050283W WO 2008004962 A2 WO2008004962 A2 WO 2008004962A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- tunnel
- sip
- subscription
- requesting
- Prior art date
Links
- 238000004891 communication Methods 0.000 title claims abstract description 13
- 238000000034 method Methods 0.000 claims abstract description 26
- 230000000977 initiatory effect Effects 0.000 claims abstract description 7
- 230000004044 response Effects 0.000 claims description 63
- 230000005641 tunneling Effects 0.000 claims description 42
- 238000010586 diagram Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
Definitions
- This invention relates to communication systems. More particularly, and not by way of limitation, the invention is directed to a system and method for reducing memory usage on both ends of a communication between servers in a communication network.
- a SIP SUBSCRIBE message is used to subscribe to changes of a state belonging to a user in the IMS network.
- SIP Session Initiation Protocol
- IMS IP Multimedia Subsystem
- a SIP NOTIFY message is sent from a Notifying server to the subscribing user.
- ASs SIP application servers
- the allocation of users to a certain instance of an AS is handled by the IMS network, and a Subscribing AS does not know which Notifying AS contains the User state.
- the Subscribing AS sends the SUBSCRIBE Message to the IMS core network which in turn routes the message to the correct Notifying AS.
- a dialogue may exist for an extended period of time, even though the number of NOTIFY messages sent may be rather low during the lifetime of the subscription. Still there is often a need to have a NOTIFY message sent in real time. Therefore, a pull-based solution is not preferred.
- the present invention provides such a system and method.
- the present invention provides a method by which a single SIP tunnel for a certain event package is utilized for multiple subscriptions between one instance of a Resource List Server (RLS) and one instance of an Application Server such as, for example, a Presence Server.
- the SIP tunnel is then used to send all SIP NOTIFY messages between these two entities to reduce memory usage at both ends by removing the overhead created by SIP.
- the invention reduces the number of SIP dialogues needed in the system to support functionality for a SIP SUBSCRIBE exploder such as the RLS. Since each SIP dialogue requires allocation of a significant amount of resources such as memory and disk space, the invention significantly reduces the amount of hardware needed.
- the invention is particularly valuable in the case of large contact lists where the number of established sessions is very large when utilizing standardized SIP signaling.
- the invention scales much better than existing solutions, and the size of the contact list does not significantly affect the dimensioning of a system in the same way as the prior art solution.
- the present invention is directed to a method of reducing memory usage in first and second servers communicating in a communication network.
- the method includes establishing a dialogue between instances of the first and second servers; and utilizing the established dialogue to tunnel all Notify messages between the instances of the first and second servers. In this manner, the number of dialogues between the first and second servers is reduced, together with the associated memory usage.
- the present invention is directed to a requesting server for providing multiple subscriptions towards multiple application servers.
- the requesting server includes means for receiving from a user, a Subscribe request requesting subscriptions to multiple resources in a contact list; means for identifying an application server for each of the resources in the contact list; means for sending to the identified application servers, a Subscribe request which includes an indication that the requesting server supports tunneling; and means for receiving a response from one of the identified application servers indicating that the identified application server also supports tunneling.
- the requesting server also includes means for determining whether the identified application server already has an existing tunnel with the first application server; and logic for determining whether the response message indicates an established tunnel already exists between the requesting server and the identified application server. If an established tunnel does not already exist between the requesting server and the identified application server, the requesting server establishes a new tunnel. If an established dialogue already exists, the requesting server utilizes the existing established tunnel to support the requested subscription.
- the present invention is directed to an application server in a communication network for providing a resource to a requesting server through a subscription.
- the application server includes means for receiving from the requesting server, a subscription request including an indication that the requesting server supports tunneling; and means for determining whether the application server supports tunneling and if so, whether a tunnel already exists between the application server and the requesting server.
- the application server also includes means for sending a first type of response to the requesting server if the application server does not support tunneling; means for sending a second type of response to the requesting server if the application server supports tunneling and a tunnel already exists between the application server and the requesting server; and means for sending a third type of response to the requesting server if the application server supports tunneling but a tunnel does not already exist between the application server and the requesting server.
- FIG. 1 is a flow chart illustrating the steps of a first exemplary embodiment of the method of the present invention
- FIG. 2 is a flow chart illustrating the steps of a second exemplary embodiment of the method of the present invention in which a new event package is used to set up a SIP-Tunnel;
- FIG. 3 is a flow chart illustrating the steps of a third exemplary embodiment of the method of the present invention; and
- FIG. 4 is a simplified block diagram of an exemplary embodiment of the system of the present invention.
- FIG. 1 is a flow chart illustrating the steps of a first exemplary embodiment of the present invention.
- a single SIP SUBSCRIBE dialogue is established for a certain event package between one instance of a Resource List Server (RLS) and one instance of an Application Server such as, for example, a Presence Server.
- RLS Resource List Server
- Application Server such as, for example, a Presence Server.
- this dialogue is then used to tunnel all SIP NOTIFY messages between these two entities inside this single dialogue to reduce memory usage at both ends by removing the overhead created by SIP.
- the invention is generic for any type of SUBSCRIBE exploder and the corresponding NOTIFY servers, or any type of application server having multiple subscriptions towards another application server.
- This embodiment makes use of the existing SIP protocol with some extensions resulting in a solution that is backwards- compatible with existing "non-tunneling" servers.
- the invention reduces the amount of memory used in IMS Networks.
- One dialogue is utilized per peer of Subscribing AS and Notifying AS.
- the single dialogue is utilized to tunnel all NOTIFY messages.
- the present invention reduces the number of dialogues to only 100 dialogues using 2 Kbytes of basic data each. Thus, a total of only 200 Kbytes of memory is required. For every user dialogue, an extra 0.1 Kbyte is needed. So instead of adding 2 Kbytes per new subscription as in the prior art, the invention adds only 0.2 Kbytes for each new subscription.
- the present invention utilizes existing IMS/SIP routing procedures to find the Notifying AS. If a dialogue already exists between these two instances, the invention informs the Subscribing AS that the NOTIFY messages will be sent in the existing "common" dialogue instead of in a separate dialogue for this particular subscription.
- the invention may also reduce the number of SIP SUBSCRIBE messages due to refresh procedures because in some cases only one dialogue needs to be refreshed. Consequently, processor resources are also saved.
- FIG. 2 is a flow chart illustrating the steps of a second exemplary embodiment of the present invention in which a new event package is used to set up a SIP-Tunnel.
- a User Equipment UE
- the RLS finds the target for the subscription, and at step 23, the RLS and the target negotiate support for SIP-tunneling.
- the SIP-Tunnel is created between the User Agent Client (UAC) and the User Agent Server (UAS) instances.
- UAC User Agent Client
- UAS User Agent Server
- the SIP-Tunnel is used for sending messages related to different subscriptions.
- FIG. 3 is a flow chart illustrating the steps of a third exemplary embodiment of the method of the present invention.
- the application server is presented as a Presence Server although other types of application servers are equally applicable.
- a UE sends a SIP SUBSCRIBE request to an RLS instance requesting the creation of a subscription to multiple resources by using a specific URI pointing at a contact list.
- the IMS core network routes the request to the RLS instance where this contact list is to be handled.
- the RLS resolves the requested contact list.
- the RLS instance sends a SIP SUBSCRIBE request to each Presence Server (PS) for the resources in the contact list requesting to create one back-end subscription for each resource in the contact list.
- PS Presence Server
- the RLS includes information in the request about its capability to support SIP tunneling, and identifies the requesting RLS instance. This information may be, for example, a new header such as "x-sip-tunneling".
- the negotiation of the actual presence back-end subscription may also be included in the request, in which case the desired expiry time of the subscription and a unique ID for the back-end subscription are also included.
- the IMS core network routes each SIP SUBSCRIBE request as normal to the correct instance of the PS based on the information in the Request- URI.
- the PS receives the SIP SUBSCRIBE request and detects the RLS capability to support SIP tunneling by examining the "x-sip-tunneling" header.
- the RLS proceeds as normal and sets up a back-end subscription without tunneling. Note that an external PS that does not support SIP tunneling will not recognize the "x-sip-tunneling" header in the SIP SUBSCRIBE request, and therefore will not return the x-sip-tunneling header in its response. Therefore, the RLS will set up a normal back-end subscription. If it is determined at step 36 that the PS supports SIP tunneling, the method moves to step 39 where the PS determines whether it already has an existing established tunnel with the requesting RLS. This may be done, for example, by checking the "contact" header value in the SIP SUBSCRIBE request and comparing the contact header value with the address of clients for its existing tunnels.
- step 41 the PS creates and stores a relation between the requested subscription and the existing established tunnel toward the RLS.
- step 42 the PS sends a response to the RLS and includes an indication that an active subscription already exists between the RLS and the PS.
- the RLS then waits for an initial notification to arrive.
- step 43 all SIP NOTIFY messages are tunneled between the RLS and the PS using the existing SIP tunnel.
- the method moves to step 44 where the PS replaces the existing tunnel with a newly created tunnel. If the new tunnel can be created successfully, the PS also creates the presence subscription based on the included parameters and ties the subscription to the tunnel. The PS returns a 200 OK to the RLS indicating that the tunnel has been created. Preferably, any errors connected with the subscription are sent in the subscription-specific headers to avoid confusing proxies that are not aware of SIP tunneling. If it is determined at step 39 that the PS does not have an existing established tunnel with this RLS, the PS does not create the subscription since the RLS will create a new SIP-Tunnel and tie a subscription to that tunnel as described below.
- This subscription is temporary, and is only used for tunnel negotiating and to find the instance of the PS.
- the method moves to step 45 where the PS returns a response to the RLS indicating that the PS supports SIP tunneling.
- the PS returns, for example, a "301 Moved Permanently" message to the RLS including information that sip-tunneling is supported.
- the PS may include the header "x-sip-tunneling" in the 301 response message to the RLS.
- the PS may optionally include an indication that a tunnel does not currently exist.
- the RLS receives the response and recognizes that the PS supports SIP tunneling.
- the RLS may determine whether a tunnel already exists utilizing the optional information placed in the contact header of the 301 response message by the PS. Alternatively, the response may not include information about the existence of a tunnel. Instead, the RLS may check the contact header against the RLS's existing tunnels. If a tunnel does not already exist, the method moves to step 47 where the RLS creates the tunnel and keeps this tunnel as long as any RLS subscription exists that requires a back-end subscription towards that PS instance (or until the system is restarted).
- This SUBSCRIBE request is a request to create a presence tunnel using, for example, a new event package called "presence. sip-tunneling". This initial request creates the tunnel and may also include information in the specific headers to create the presence subscription to avoid extra signaling.
- the "expires" header includes the configured "SIP Tunnel Expires Value”.
- both the RLS and the PS have a subscription-dialogue relation between the RLS instance and the PS instance. Any new subscription created between that particular RLS/PS instance pair will use the same established dialogue and corresponding tunnel. Whenever a request related to a subscription is sent, it uses the corresponding tunnel. In this case the standard SIP headers are used for information related to the tunnel, and specific header and body information is used for the information related to the subscription. If the RLS receives a subscribe refresh request from the client, the RLS proceeds as normal and refreshes the subscription towards the PS. Note that the RLS only refreshes the SIP Tunnel subscription towards the PS if the remaining time of the existing dialogue is shorter than the expiry time of the received subscription. The RLS may handle refresh of the tunnel in different ways such as:
- the RLS/PS refreshes the SIP tunnel as long as any subscription exists between the RLS and the PS by using a configurable expiration time (which is the same in both the RLS and the PS) but without sending the refresh messages.
- SIP Tunnel refreshed when subscription is refreshed/created In this case, the SIP tunnel is refreshed when a back-end subscription is created/refreshed using a configurable expiration time. 3. SIP Tunnel is refreshed explicitly - A separate thread is used in the
- the RLS to refresh the SIP tunnel as long as any back-end subscriptions exist.
- the RLS desires to refresh the SIP Tunnel, the RLS does not include the "x-sub- data" header in the Refresh message.
- the x-sub-data header is included when any change occurs in the back-end subscription.
- the RLS refreshes the back-end subscription and includes the ID of the specific back-end subscription. If only the SIP tunnel is to be refreshed, the RLS does not include the ID of the specific back-end subscription.
- the SIP tunneling function is also very useful when subscribing to XCAP changes, for example, especially if the XDMS and AS are not co-located.
- the use of timers on the particular subscription may also be avoided, with timers being used only on the SIP tunnel.
- timers are not used in the PS because the RLS terminates all back-end subscriptions when the subscription times out.
- a drawback to this approach is that there may be "hanging" subscriptions in the PS.
- a specific clean-up thread may be implemented to remove all subscriptions that have an elapsed expiration time.
- the memory savings achieved by the present invention depends on the distribution of the contacts (i.e., presentities) on different addresses (processors). For example, from the RLS point of view, if all contacts are located on the same processor, the greatest memory saving is achieved. There is progressively less savings as more and more of the contacts are located on different processors.
- the base for the solution is to make use of the existing SIP protocol to find the correct instance of the Presence Server with a few extensions resulting in a solution that is backwards compatible with existing "non-tunneling" servers.
- a new header called "x-sip-tunneling” is used to negotiate the support for SIP tunneling. Note that it is not allowed to use the supported header for proprietary extensions if it is not part of an RFC. This can, however, be proposed as an extension if needed in the future.
- the information about the RLS instance (IP-address/port) sending the request is included in the contact header in the subscribe request as normal.
- the RLS sets up a Tunnel towards that instance of the PS to create a SIP Dialogue using the RLS and PS server addresses as To/From information. Since the information in these messages is different from the standard Presence event package, it is preferable to use a new event package called, for example, "presence. sip-tunneling".
- Presence. sip-tunneling a new event package called, for example, "presence. sip-tunneling".
- the reason for specifying the application is that it may be used for several applications (such as subscriptions from AS to XDMS) and thus it is necessary to point out the correct application.
- the information about the specific subscription is included in specific headers of the SIP SUBSCRIBE/SIP NOTIFY request and in the response to these requests.
- the SIP request includes information that relates to the SIP tunnel as well as information that relates to the individual subscription. In this way, information may be exchanged between the end-point applications (e.g., RLS and PS) without affecting any proxies.
- end-point applications e.g., RLS and PS
- a proxy must be able to handle standard routing based on the IP-address/port in the request. The proxy must also be able to handle the new event package.
- the request/response always includes the specific "x-sub-data" to identify the specific subscription.
- SIP Tunnel Subscribe Requests The Subscribe request related to a subscription using the tunnel may be either a refresh or a terminate request since initial subscriptions utilize a standard presence subscribe.
- the RLS uses the received contact address in the Request-URI and To headers.
- the RLS also includes the contact address of the RLS instance (TP) in the P-Asserted-ldentity as well as in the From header.
- TP contact address of the RLS instance
- other information may be used in the To, From, and P-Asserted-ldentity and then the contact information is used as usual only in the Request-URI and Contact.
- the Subscribe request also includes a "presence. sip-tunneling" event package, and preferably utilizes a specific header "x-sub-data" to convey all information about the subscription.
- the Subscribe request may include:
- the SIP Subscribe response includes specific information for the subscription.
- x-sub-data header is utilized to convey all information about the subscription.
- the x-sub-data header may take the form,
- the response may include one header for each parameter such as "x-sub-id" to indicate the related subscription, "x-sub-expires” to indicate the determined time for the subscription, and "x-sub-response” to indicate the response code for the particular subscription.
- the Notify request related to a subscription using the tunnel must include specific headers for the subscription so that the tunnel is kept “unaware" of the subscription.
- the Notify request preferably includes a specific header "x-sub-data" where all information about the subscription is included.
- the response may include one header for each parameter such as "x-sub-id” to indicate whether the response relates to the subscription or the tunnel, and "x-sub-state” to indicate the status for the presence subscription (Equivalent to Subscription-State). For example, if x-sub-state says "terminated”, it indicates for the RLS that the Presence server has terminated the subscription.
- the RLS and the PS must still store information unique for each particular subscription that is not directly related to the SIP Tunnel (SIP Dialogue). Depending on how much data is related to the subscription, the amount of memory utilized will differ, but the saving of memory related to the SIP Tunnel is still the same.
- FIG. 4 is a simplified block diagram of an exemplary embodiment of the system of the present invention.
- User equipment (UE) 51 sends a SIP SUBSCRIBE request message 52 via an IMS core network 53 to an RLS instance 54 requesting the creation of a subscription to multiple resources by using a specific URI pointing at a contact list.
- a contact list resolver 55 in the RLS resolves the requested list.
- a SIP SUBSCRIBE generator 56 in the RLS sends SIP SUBSCRIBE requests 57 to the application server for each contact via the IMS core network.
- a Presence Server (PS) 58 is illustrated here.
- PS Presence Server
- the RLS includes information in the request about its ability to support SIP tunneling, and identifies the requesting RLS instance. This information may be, for example, a new value such as "sip- tunneling" in the "supported" header.
- the PS 58 receives the SIP SUBSCRIBE request 57 and detects the capability of the RLS 34 to support SIP tunneling by examining the "supported" header.
- An existing tunnel determination unit 59 in the PS determines whether it already has an existing established tunnel with the requesting RLS by comparing the "contact" header value with the information that is stored in the PS about ongoing subscriptions. This information may be stored in a subscription-tunnel relation database 61.
- a subscription creator 62 in the PS creates a new subscription. lnformation about the new subscription is stored in the subscription-tunnel database.
- the PS may utilize the "contact" header value in the SIP SUBSCRIBE request 57 to identify the RLS instance, and stores information that ties a specific subscription to a specific RLS instance.
- the PS 58 returns a response to the RLS 54 via the IMS core network with an ID identifying the new or existing subscription. If the PS did not have an existing established tunnel with the RLS 54, a 200 OK response 63 may be generated by a SIP 200 OK message generator 64. If the PS had an existing established tunnel with the RLS, a 301 response 65 may be generated by a SIP 301 response generator 66.
- the RLS 54 receives the response, and an existing PS subscription determination unit 67 in the RLS determines whether a subscription already exists to this PS instance by examining the received response. If a 200 OK response 63 is received, the RLS knows that no subscription exists. If a "301" response 65 is received, the RLS knows that a subscription already exists. If a subscription does not exist, a subscription-tunnel relation creator 68 in the RLS uses the information in the contact header of the 200 OK response message to create a new subscription-tunnel relation towards that particular instance of the PS 58. The RLS stores the subscription-dialogue relation locally in a subscription-tunnel relation database 69 as long as the RLS subscription exists.
- the RLS uses the information in the contact header of the 301 response message to create a subscription-dialogue relation between the incoming RLS subscription and the already existing dialogue towards the PS.
- the RLS stores the subscription-dialogue relation locally in the subscription-tunnel database 69 as long as the RLS subscription exists.
- the RLS also returns a unique ID pointing out the specific subscription- tunnel relation for this particular subscription. This information could be included either in an extra route header or in an additional header used by the RLS internally. Thereafter, any new subscription created between that particular RLS/PS instance pair will use the same established dialogue.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
- Communication Control (AREA)
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
MX2008015285A MX2008015285A (en) | 2006-07-06 | 2007-04-27 | Reduced memory usage between communication servers. |
GB0901649A GB2453493B (en) | 2006-07-06 | 2007-04-27 | System and method for reducing required memory usage between communication servers |
CN200780025436.4A CN101485155B (en) | 2006-07-06 | 2007-04-27 | System and method for reducing required memory usage between communication servers |
CA002655427A CA2655427A1 (en) | 2006-07-06 | 2007-04-27 | System and method for reducing required memory usage between communication servers |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US80665606P | 2006-07-06 | 2006-07-06 | |
US60/806,656 | 2006-07-06 | ||
US11/559,203 | 2006-11-13 | ||
US11/559,203 US8051129B2 (en) | 2006-07-06 | 2006-11-13 | Arrangement and method for reducing required memory usage between communication servers |
US11/674,861 US8230074B2 (en) | 2006-07-06 | 2007-02-14 | System and method for reducing required memory usage between communication servers |
US11/674,861 | 2007-02-14 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2008004962A2 true WO2008004962A2 (en) | 2008-01-10 |
WO2008004962A3 WO2008004962A3 (en) | 2008-04-03 |
Family
ID=38895035
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/SE2007/050283 WO2008004962A2 (en) | 2006-07-06 | 2007-04-27 | Reduced memory usage between communication servers |
Country Status (6)
Country | Link |
---|---|
US (1) | US8230074B2 (en) |
CN (1) | CN101485155B (en) |
CA (1) | CA2655427A1 (en) |
GB (1) | GB2453493B (en) |
MX (1) | MX2008015285A (en) |
WO (1) | WO2008004962A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8332516B2 (en) | 2009-12-08 | 2012-12-11 | International Business Machines Corporation | Optimized cooperation between resource list servers and presence servers |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7987506B1 (en) * | 2006-11-03 | 2011-07-26 | Cisco Technology, Inc. | Methods and systems for dynamically updating a routing table in a virtual private network |
CN102177764B (en) * | 2008-08-01 | 2014-02-19 | 泰克莱克股份有限公司 | Methods, systems, and computer readable media for session initiation protocol (SIP) dialog identification |
US7979567B2 (en) * | 2008-12-17 | 2011-07-12 | International Buisness Machines Corporation | Sharing of subscriptions to resource list content in resource list server |
US20110231560A1 (en) * | 2009-09-11 | 2011-09-22 | Arungundram Chandrasekaran Mahendran | User Equipment (UE) Session Notification in a Collaborative Communication Session |
CN102056147B (en) * | 2009-10-29 | 2014-12-10 | 中兴通讯股份有限公司 | Method and system for subscribing service in IP (Internet Protocol) multimedia subsystem network |
CN102209313A (en) * | 2010-03-29 | 2011-10-05 | 华为技术有限公司 | Presence information subscribing method and system, resource list server and presence server |
EP2583447B1 (en) * | 2010-06-21 | 2018-11-28 | Telefonaktiebolaget LM Ericsson (publ) | Method and arrangement for notifications in a communication network |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020103898A1 (en) * | 2001-01-31 | 2002-08-01 | Moyer Stanley L. | System and method for using session initiation protocol (SIP) to communicate with networked appliances |
US20050010758A1 (en) * | 2001-08-10 | 2005-01-13 | Peter Landrock | Data certification method and apparatus |
US20050232408A1 (en) * | 2004-04-15 | 2005-10-20 | Hodson Jeffrey D | System for contact system entities beyond end-points to track state availability and capabilites by implementing SIP presence technologies |
WO2006108168A2 (en) * | 2005-04-01 | 2006-10-12 | Verizon Services Corp. | Interworking qsig and h.323 signaling in a sip-based network |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6912522B2 (en) * | 2000-09-11 | 2005-06-28 | Ablesoft, Inc. | System, method and computer program product for optimization and acceleration of data transport and processing |
US20040003046A1 (en) * | 2001-12-12 | 2004-01-01 | 3Com Corporation | System and methods for providing instant services in an internet protocol network |
KR100605806B1 (en) * | 2004-06-10 | 2006-08-01 | 삼성전자주식회사 | A phone-based mobile internet protocol, voice over internet protocol, and session initiation protocol, session initiation protocol server, and routing path control method and system for session initiation protocol service |
US7778199B2 (en) * | 2005-02-19 | 2010-08-17 | Cisco Technology, Inc. | Techniques for customer self-provisioning of edge nodes for a virtual private network |
CN101163139B (en) * | 2006-10-11 | 2010-12-15 | 国际商业机器公司 | Method and equipment for refusing SIP message of redundancy retransmission |
-
2007
- 2007-02-14 US US11/674,861 patent/US8230074B2/en not_active Expired - Fee Related
- 2007-04-27 CA CA002655427A patent/CA2655427A1/en not_active Abandoned
- 2007-04-27 WO PCT/SE2007/050283 patent/WO2008004962A2/en active Application Filing
- 2007-04-27 CN CN200780025436.4A patent/CN101485155B/en not_active Expired - Fee Related
- 2007-04-27 MX MX2008015285A patent/MX2008015285A/en active IP Right Grant
- 2007-04-27 GB GB0901649A patent/GB2453493B/en not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020103898A1 (en) * | 2001-01-31 | 2002-08-01 | Moyer Stanley L. | System and method for using session initiation protocol (SIP) to communicate with networked appliances |
US20050010758A1 (en) * | 2001-08-10 | 2005-01-13 | Peter Landrock | Data certification method and apparatus |
US20050232408A1 (en) * | 2004-04-15 | 2005-10-20 | Hodson Jeffrey D | System for contact system entities beyond end-points to track state availability and capabilites by implementing SIP presence technologies |
WO2006108168A2 (en) * | 2005-04-01 | 2006-10-12 | Verizon Services Corp. | Interworking qsig and h.323 signaling in a sip-based network |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8332516B2 (en) | 2009-12-08 | 2012-12-11 | International Business Machines Corporation | Optimized cooperation between resource list servers and presence servers |
US8874753B2 (en) | 2009-12-08 | 2014-10-28 | International Business Machines Corporation | Optimized cooperation between resource list servers and presence servers |
Also Published As
Publication number | Publication date |
---|---|
US20080008185A1 (en) | 2008-01-10 |
MX2008015285A (en) | 2008-12-12 |
CA2655427A1 (en) | 2008-01-10 |
WO2008004962A3 (en) | 2008-04-03 |
GB2453493A (en) | 2009-04-08 |
GB2453493B (en) | 2010-12-29 |
CN101485155A (en) | 2009-07-15 |
US8230074B2 (en) | 2012-07-24 |
CN101485155B (en) | 2012-05-30 |
GB0901649D0 (en) | 2009-03-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8230074B2 (en) | System and method for reducing required memory usage between communication servers | |
KR101430442B1 (en) | Method for updating session using network-based management of capability of terminal | |
US8661077B2 (en) | Methods, systems and computer readable media for providing a failover measure using watcher information (WINFO) architecture | |
EP2213069B1 (en) | Establishing a multimedia communications session | |
US9143537B2 (en) | Device registration in an IMS network | |
US8209432B2 (en) | Method and arrangement for communicating multimedia content | |
EP3453154A1 (en) | Restoration of serving call session control and application server function | |
US9392070B2 (en) | Method and arrangement for handling resource data | |
US10305942B2 (en) | SIP server with multiple identifiers | |
JP5173607B2 (en) | Communications system | |
CN101326493A (en) | Method and device for distributing load of multiprocessor server | |
EP1720320A1 (en) | A method and arrangement for handling client-related information in an application server | |
US8553724B2 (en) | Enhanced dynamic compression | |
EP2028826A1 (en) | SIP-based user registration method, system, terminal and server | |
US20080256177A1 (en) | Method and Apparatus for Maintaining Information at an Ims Client | |
EP2068524A1 (en) | A method and a system for acquiring the transmission path of the sip message | |
US20100312847A1 (en) | Method for authorizing a watcher by providing watcher specific information to the presentity | |
WO2006118529A2 (en) | A method and arrangement for handling client-related information in an application server | |
US8051129B2 (en) | Arrangement and method for reducing required memory usage between communication servers | |
EP2146479A1 (en) | SIP server and communication system | |
EP2532143B1 (en) | Method and apparatus for routing xcap requests | |
CN101383817A (en) | Method and system for non-SIP service method access control, service register center | |
CN111949918B (en) | Websocket connection optimization method and system based on distributed environment | |
EP3761587B1 (en) | Method for infinity registration using a session initiation protocol based communication in a session initiation protocol based network, and network | |
KR101689196B1 (en) | Method for transmitting and receiving session history in communication system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200780025436.4 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07748444 Country of ref document: EP Kind code of ref document: A2 |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: MX/a/2008/015285 Country of ref document: MX |
|
ENP | Entry into the national phase |
Ref document number: 2655427 Country of ref document: CA |
|
WWE | Wipo information: entry into national phase |
Ref document number: 21/DELNP/2009 Country of ref document: IN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 0901649 Country of ref document: GB Kind code of ref document: A Free format text: PCT FILING DATE = 20070427 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 0901649.4 Country of ref document: GB |
|
NENP | Non-entry into the national phase |
Ref country code: RU |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 07748444 Country of ref document: EP Kind code of ref document: A2 |