WO2008041830A1 - Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence - Google Patents

Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence Download PDF

Info

Publication number
WO2008041830A1
WO2008041830A1 PCT/KR2007/004853 KR2007004853W WO2008041830A1 WO 2008041830 A1 WO2008041830 A1 WO 2008041830A1 KR 2007004853 W KR2007004853 W KR 2007004853W WO 2008041830 A1 WO2008041830 A1 WO 2008041830A1
Authority
WO
WIPO (PCT)
Prior art keywords
rls
presentities
notification
notifications
presence information
Prior art date
Application number
PCT/KR2007/004853
Other languages
English (en)
Other versions
WO2008041830A8 (fr
Inventor
Jae-Kwon Oh
Basavaraj Jayawant Pattan
Original Assignee
Samsung Electronics Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co., Ltd. filed Critical Samsung Electronics Co., Ltd.
Publication of WO2008041830A1 publication Critical patent/WO2008041830A1/fr
Publication of WO2008041830A8 publication Critical patent/WO2008041830A8/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • 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
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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

  • the present invention in general relates to mobile communication.
  • the present invention relates to various OMA developed applications over SIP (Session Initiation Protocol), such as Instant Messaging, Push to talk over Cellular, Converged IP Messaging and any other future applications that utilize presence service.
  • SIP Session Initiation Protocol
  • the present invention relates to those applications which subscribe to and receive notifications about presence information. More particularly, this invention relates to an RLS (Resource List Server) notification rule for multiple presentities.
  • RLS Resource List Server
  • Presence system architecture helps to share the presence information of any user to other users.
  • the presence information is basically the information related to the user, like current location of the user, contact information of the user and application specific presence information, such as if the user is available for IM (Instant Message) etc.
  • IM Instant Message
  • the user has to subscribe to the presence information of other users in order to receive presence information of other users.
  • the requested user authorizes reception of his presence information by the requesting user.
  • the presence server entity maintains the presence subscription of the requesting user and also stores the presence information of the requested user. As soon as presence information of the requested user changes, the presence server sends the notifications to the subscribing/requesting user during the period when the subscription is still valid.
  • the Watcher is basically users who are authorized to watch the presence information of another user.
  • the SIP SUBSCIBE and SIP NOTIFY methods are used for subscribing and notifying.
  • a User registered to Presence Service can subscribe to presence information of an individual or a group of presentities.
  • SIP SUBSCRIBE will specify the URI of the resource list that lists the group of presentities as specified in IETF RFC 4662 "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", or will consist of a URI list as specified in IETF draft draft-ietf- sip-uri-list-subscribe "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)".
  • SIP Session Initiation Protocol
  • URI-list service will handle such SIP SUBSCRIBE and SIP NOTIFY as specified in IETF draft draft-ietf-sipping-uri- services "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services.”
  • SIP Session Initiation Protocol
  • URI Uniform Resource Identifier
  • a Watcher receives composite notification for a group of presentities from RLS.
  • Such composite notification from the RLS contains a group of notifications respectively from a set of presentities. There is no association of the notifications received from one user with another user.
  • Bill's and Ted's presence information are "CLOSED," and Joe's presence information is "OPEN.”
  • Bill 50 has a service subscription with the same operator as to which Adam 10 has a service subscription
  • Joe 60 and Ted 70 has service subscriptions with another operator.
  • Adam's Client 10 sends a single list presence subscription request (complying to draft-ietf-sip-uri-list-subscribe) to the RLS (Resource List Server) 20 containing a filter (complying to IETF RFC 4660) at step 100.
  • RLS Resource List Server
  • SUBSCRIBE is used for subscription requests.
  • the list contains the subscription requests to Bill, Joe and Ted, and the filter rule specifies to send notifications when Bill, Joe and Ted's presence information are "OPEN.”
  • Presence-Server-A Presence-Server-A
  • Presence- S erver-B Presence-B 40
  • steps 105 and 110 Presence-Server-A 30
  • Presence-Server-A 30 is then provided with PUBLISH from Bill 50 and monitors the presence information of Bill 50.
  • NOTIFY is used for the notifications.
  • Presence-Server-B 40 is provides with PUBLISH from Joe 60, and then monitors the presence information of Joe 60.
  • Presence-Server-B 40 if required, filters the presence information, and then Presence-Server-B 40 immediately sends notifications to the RSL 20 at step 140 if the presence information of Joe is "OPEN.” Therefore, the RLS 20 combines notifications at step 145 and sends the notification to Adam 10 (with consideration of notification speed, etc.), thereby allowing Adam 10 to be aware that Joe 60 is "OPEN.”
  • Presence-Server-B 40 is provided with PUBLISH from Ted 70 and then monitors the presence information of Ted 70 at step 155.
  • Presence- Server-B 40 if required, filters the presence information, and then sends a notification at step 165 only when Ted 70 changes his presence to "OPEN.” Therefore, RLS 20 sends the notification to Adam 10 at step 170.
  • Adam may receive Bill's, Joe's, and Ted's "OPEN" presence information in multiple notifications.
  • Adam has to monitor manually if the arrived notifications meet his requirement that all of Bill, Joe and Ted should be "OPEN.”
  • Adam 10 monitors the multiple notifications at step 175. Then, when all of Bill's, Joe's and Ted's presence information are "OPEN," Adam invites them to the conference.
  • overload may be caused if the User receives notifications from a number of users whenever the presence information changes while the User subscribes to the presence information. Further, it is an unnecessary and annoying task for the Watcher to receive every notification. Therefore, it is necessary to optimize the presence notifications by avoiding the unnecessary and annoying notifications.
  • the Watcher receives presence information from a group of presentities, the Client has to evaluate against the notification rule set by the User (stored in Client) before presenting the presence information to the User. But, authors are not aware of such client implementations.
  • the present invention has been made to solve the above- mentioned problems occurring in the prior art, and the present invention provides a system and method for allowing a user to specify the choice of how and when the RLS has to generate NOTIFY requests.
  • This invention allows a user to specify how and when the RLS has to generate notifications, thereby optimizing notifications.
  • this invention provides good user experience and reduces service cost.
  • FIG 1 illustrates the entities involved for the use case considered in this invention
  • FIG. 2 illustrates the flow for current art for the use case considered in this invention.
  • FIG 3 illustrates the flow for invention for the use case considered in this invention.
  • the present invention provides a system and method for allowing a user to specify the choice of how and when the RLS has to generate NOTIFY requests. As a result, it becomes possible to optimize the presence notifications by avoiding unnecessary and sometimes annoying notifications. This is possible by allowing user to specify RLS notification rule in the initial SIP SUBSCRIBE. Therefore, the present invention allows the Watcher to specify filters in SIP SUBSCRIBE. The present invention further indicates the expected behavior of RLS when such RLS notification rules exist in SIP SUBSCRIBE.
  • RLS Notification Rule in the initial SIP SUBSCRIBE, which can also contains either the URI list in the format as specified in "draft-ietf-sip-uri-list-subscribe", or the URI of the URI list as specified in RFC 4662.
  • the format of the RLS Notification Rule can be defined by content type, for example, "application/rls-notification-rule.”
  • the rules differ based on the "operation type.” The operation type could be divided into "ALL”, “ATLEAST”, “ATMOST”, “EQUALS”, and any other.
  • Table 1 means that the Watcher is interested in notifications only when all the notifications are received from the list of users specified in the rule. Also, an example format for the operation type "ATLEAST" is shown in table 2 below.
  • Table 2 means that the Watcher is interested in notifications only when at- least "x" number of notifications are received from the list of users specified in the rule.
  • Table 3 means that the Watcher is interested in notifications only when at- most "x" number of notifications are received from the list of users specified in the rule.
  • Table 4 means that the Watcher is interested in notifications only when "x" number of notifications are received from the list of users mentioned in the rule.
  • ⁇ list> element is optional in all the notification rules specified above, and if not present, then the operation is applied to all the presentities mentioned in resource-lists.
  • the invention does not restrict the RLS Notification Rules to the above mentioned operation types, but also the RLS Notification Rules can contain any user directives that control the RLS notification.
  • RLS stores the Notification Rule:
  • the URI List Service On reception of a SIP SUBSCRIBE request with a URI-list containing rls-notification-rule, the URI List Service will comply with RFC 4662 for creating the subscription and receiving the changes in the resources within the created dialog.
  • the rls-notification-rule is associated with the dialog and is stored by the URI List Service.
  • the URI List Service On receiving the presence notifications from multiple resources, the URI List Service evaluates the notifications against the rls-notification-rule and only for successful evaluation are the presence notifications delivered to the Watcher. Otherwise, the notification is not sent to the Watcher.
  • the sequence of operations for the use case considered in this invention can be explained as below.
  • Bill's and Ted's presence information are "CLOSED,” but Joe's presence information is "OPEN.” It is also assumed that Bill has a service subscription to the operator where Adam has service subscription, and Joe and Ted have service subscriptions with another operator.
  • Adam 10 sends a single list presence subscription request (complying to draft-ietf-sip-uri-list-subscribe) to the RLS 20 containing a filter (complying to IETF RFC 4660) at step 300.
  • the list contains the subscription requests for Bill 50, Joe and Ted 60 and 70.
  • the filter rule specifies to send notifications when presence information of Bill 50, Joe and Ted 60 and 70 are "OPEN.” Additionally Adam 10 specifies an rls-notification-rule that instructs the RLS to send the notifications to Adam 10 only when the RLS 20 receives all presence information from Bill 50, Joe and Ted 60 and 70.
  • the RLS 20 determines if there is rls-notification-rule at step 305, and then spawns the subscription request containing the filter to Presence-Server-A 30 and Presence-Server-B 40 at steps 310 and 315.
  • the rls-notification-rule is excluded from the subscription request, as it is only valid for the RLS 20.
  • Presence-Server-A 30 is provided with PUBLISH from Bill 50 at step 320 and monitors the presence information of Bill 50. Presence-Server-A 30, if required, filters the presence information at step 325, and then sends notification to the RLS 20 only when Bill 50 changes his presence to "OPEN" at step 330. NOTIFY is used for this notification.
  • Presence- Server-B 40 monitors the presence information of Joe and Ted 60 and 70. Accordingly, Presence-Server-B 40 is provided with PUBLISH from Joe 60 at step 335, and then, if required, filters the presence information at step 340. Since the presence information of Joe 60 is "OPEN,” notification for the presence information of Joe is sent immediately from Presence-Server-B 40 to RLS 20. However, as the presence information of Ted 70 is not "OPEN" yet, and thus does not suffice the rls-notif ⁇ cation-rule, it is not notified yet.
  • the RLS 20 has received notifications from Bill 50 and Joe 60 by now, it does not satisfy the rls-notification-rule as the presence information from Ted 70 has not been received yet. As such, the RLS 20 holds up the delivery of notifications to Adam 10 until it receives one from Ted 70.
  • Presence-Server-B 40 For Ted, Presence-Server-B 40 is provided with PUBLISH from Ted 70 at step 355 and monitors the presence information of Ted 70. Accordingly, Presence- Server-B 4, if required, filters the presence information at step 360, and then sends the notification to the RLS when Ted changes his presence to "OPEN" at step 365.
  • RLS can receive the presence information of Ted 70. Accordingly, the RLS 20 determines if the rls-notification-rule is met at step 370. As the RLS 20 has presence information of all of Bill's, Joe's, and Ted's, the rls- notification-rule is now met and thus RLS 20 sends the composite notification to Adam 10.
  • Adam 10 receives Bill, Joe and Ted's "OPEN" presence information in a single notification from RLS 20. As all of Bill, Joe and Ted's presence information is "OPEN," Adam 10 invites them to the conference.
  • a User is allowed to specify rls- notification-rule in the SIP SUBSCRIBE body containing subscription to a list of resources in SIP which is being sent to the RLS or URI List Service.
  • the RLS server or URJ List Service performs the additional role of the storing rls- notification-rule and also of monitoring presence information arriving from a group of presentities and evaluating the rls-notification-rule.
  • STEP 1 Changes in SIP SUBSCRIBE
  • STEP 2 Changes in role of RLS server or URI List Service
  • the URI List Service Upon reception of a SIP SUBSCRIBE request with a URI-list containing an rls-notification-rule, the URI List Service will comply with RFC 4662 for creating the subscription and receiving the changes in the resources within the created dialog.
  • the RLS notification rule is associated with the dialog and is stored by the URI List Service.
  • the URI List Service Upon receiving the presence notifications from multiple resources, the URI List Service evaluates the RLS notification against the rls-notification-rule, and only for successful evaluation are the presence notifications delivered to the Watcher.
  • RLS Notification Rules are as follows.
  • a Watcher when subscribing to a presence list, may be able to set some conditions to control the triggers of notifications.
  • the Watcher can specify when it is intended to receive Presence Information of a group of presentities from RLS.
  • the Watcher wants to set some rules while subscribing to a Presence List, he/she can send a SIP SUBSCRIBE request according to IETF RFC 3265 "Session Initiation Protocol (S ⁇ P)-Specific Event Notification" with the following clarifications.
  • Watcher wants to send Event Notification Filtering Rules IETF RFC 4660 "Functional Description of Event Notification Filtering" and RLS Notification Rules, he/she can include value "multipart/related" in the Content- Type header in order to aggregate "application/simple-filter+xml” and "application/vnd.oma.rls-notification-rules+xml” content types.
  • RLS Notification Rules conform to the structure and semantics as described below.
  • the root element ⁇ rule-set> can include any other attribute for the purposes of extensibility, can include a ⁇ ns-bindings> element that contains the namespace bindings, and includes one or more ⁇ rule-set > elements that contain the conditions for RLS notification delivery.
  • the ⁇ ns-bindings> element includes one or more ⁇ ns-binding> elements, each of which contains the binding between the prefix and the namespace in a "prefix" attribute and a "namespace” attribute, respectively. This is used to express the list of URIs for whom the condition has to be applied using the format of resource-list as described in [RFC4826].
  • the ⁇ rule> element includes an "id" attribute that contains the unique identification for the condition, includes zero or more ⁇ trigger> elements that contains the operation types which trigger the RLS notifications, and can include any other elements from other namespaces for the purposes of extensibility.
  • the ⁇ trigger> element includes zero or more ⁇ operation> elements, each of which contains the operation type to be applied, and can include any other elements from other namespaces for the purposes of extensibility.
  • the ⁇ operation> element includes a "type" attribute that specifies how to apply the trigger for the URIs listed as child elements, can include zero or one ⁇ list> elements that contains the URIs of resources as described in [RFC4826], and can include any other elements from other namespaces for the purposes of extensibility.
  • the RLS can support RLS Notification Rules set by the Watcher in the SIP SUBSCRIBE request to a Presence List.
  • the RLS on receiving the SUBSCRIBE request to a presence list with RLS Notification Rules, follows the procedures as below.
  • the RLS supports the Content-Type "application/vnd.oma.rls- notification-rules+xml" as described in table 6.
  • the RLS Upon receiving the SIP SUBSCRIBE request with the RLS Notification Rules, the RLS validates the embedded conditions and stores the RLS Notification Rules. Then, the RLS does not include the RLS notification rules to the SIP SUBSCRIBE requests since the RLS Notification Rules is only valid for the RLS.
  • RLS buffers the received notifications from the list of presentities and deliver them to the Watcher when the specified conditions are met.
  • This invention allows a user to specify how and when the RLS has to generate notifications, thereby optimizing notifications.
  • this invention provides good user experience and reduces service cost.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système et un procédé pouvant permettre à un utilisateur de déterminer le choix quant à la manière et à quel moment le serveur de listes de ressources doit générer des demandes de notification. En conséquence, il est possible d'optimiser les notifications de présence en évitant des notifications inutiles et parfois importunes. Ceci est possible en permettant à un utilisateur de déterminer la règle de notification du serveur de listes de ressources dans SUBSCRIBE SIP initial. En conséquence, cette invention permet à l'observateur de déterminer des filtres dans SUBSCRIBE SIP. Cette invention indique également le comportement attendu d'un serveur de listes de ressources lorsque ces règles de notification concernant le serveur de listes de ressources existent dans SIP SUBSCRIBE.
PCT/KR2007/004853 2006-10-03 2007-10-04 Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence WO2008041830A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN1819/CHE/2006 2006-10-03
IN1819CH2006 2006-10-03

Publications (2)

Publication Number Publication Date
WO2008041830A1 true WO2008041830A1 (fr) 2008-04-10
WO2008041830A8 WO2008041830A8 (fr) 2008-10-16

Family

ID=39268652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2007/004853 WO2008041830A1 (fr) 2006-10-03 2007-10-04 Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence

Country Status (2)

Country Link
KR (1) KR101378217B1 (fr)
WO (1) WO2008041830A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100077018A1 (en) * 2008-09-19 2010-03-25 Arup Acharya Virtual Presence Server
FR2942928A1 (fr) * 2009-03-03 2010-09-10 Alcatel Lucent Procede et systeme de gestion multicriteres de notifications de presence
FR2965999A1 (fr) * 2010-10-12 2012-04-13 France Telecom Procede de traitement des flux de presence dans un reseau sip
WO2012128683A1 (fr) * 2011-03-23 2012-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et système pour contrôler des actions dans un service de notification
WO2013104429A1 (fr) * 2012-01-13 2013-07-18 Telefonaktiebolaget L M Ericsson (Publ) Procédés et appareil de configuration et de mise en œuvre d'annonces pour des services supplémentaires d'un sous-système multimédia ip

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040071150A1 (en) * 2002-07-05 2004-04-15 Anu Honkala Updating presence information
US20040122977A1 (en) * 2002-12-19 2004-06-24 Moran Timothy L. Filtering application services
EP1441486A2 (fr) * 2003-01-22 2004-07-28 Nec Corporation Système de présence
US20040177134A1 (en) * 2002-07-16 2004-09-09 Nokia Corporation System, apparatus and method for providing partial presence notifications
US20050250481A1 (en) * 2004-05-04 2005-11-10 Nokia Corporation Communication system for handling subscriber requests
KR20060059583A (ko) * 2004-11-29 2006-06-02 주식회사 나라비전 Ｓｉｐ 프로토콜을 이용한 프리젠스 서비스 방법 및 이를 위한 확장된 프리젠스 정보를 위한 ｘｍｌ 데이터 구조가 저장되는 기록매체

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040071150A1 (en) * 2002-07-05 2004-04-15 Anu Honkala Updating presence information
US20040177134A1 (en) * 2002-07-16 2004-09-09 Nokia Corporation System, apparatus and method for providing partial presence notifications
US20040122977A1 (en) * 2002-12-19 2004-06-24 Moran Timothy L. Filtering application services
EP1441486A2 (fr) * 2003-01-22 2004-07-28 Nec Corporation Système de présence
US20050250481A1 (en) * 2004-05-04 2005-11-10 Nokia Corporation Communication system for handling subscriber requests
KR20060059583A (ko) * 2004-11-29 2006-06-02 주식회사 나라비전 Ｓｉｐ 프로토콜을 이용한 프리젠스 서비스 방법 및 이를 위한 확장된 프리젠스 정보를 위한 ｘｍｌ 데이터 구조가 저장되는 기록매체

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8447808B2 (en) * 2008-09-19 2013-05-21 International Business Machines Corporation Virtual presence server
US20100077018A1 (en) * 2008-09-19 2010-03-25 Arup Acharya Virtual Presence Server
FR2942928A1 (fr) * 2009-03-03 2010-09-10 Alcatel Lucent Procede et systeme de gestion multicriteres de notifications de presence
WO2010100354A1 (fr) 2009-03-03 2010-09-10 Alcatel Lucent Procédé et système de gestion multicritères de notifications de présence
US8930488B2 (en) 2009-03-03 2015-01-06 Alcatel Lucent Method and system for the multi-criteria management of presence notifications
FR2965999A1 (fr) * 2010-10-12 2012-04-13 France Telecom Procede de traitement des flux de presence dans un reseau sip
WO2012049404A1 (fr) * 2010-10-12 2012-04-19 France Telecom Procede de traitement des flux de presence dans un reseau sip
WO2012128683A1 (fr) * 2011-03-23 2012-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et système pour contrôler des actions dans un service de notification
EP2689572A1 (fr) * 2011-03-23 2014-01-29 Telefonaktiebolaget L M Ericsson (PUBL) Procédé et système pour contrôler des actions dans un service de notification
EP2689572A4 (fr) * 2011-03-23 2015-01-21 Ericsson Telefon Ab L M Procédé et système pour contrôler des actions dans un service de notification
WO2013104429A1 (fr) * 2012-01-13 2013-07-18 Telefonaktiebolaget L M Ericsson (Publ) Procédés et appareil de configuration et de mise en œuvre d'annonces pour des services supplémentaires d'un sous-système multimédia ip
CN104040991A (zh) * 2012-01-13 2014-09-10 瑞典爱立信有限公司 用于为ip多媒体子系统补充服务配置和实现通知的方法和设备
US10298696B2 (en) 2012-01-13 2019-05-21 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for configuring and implementing announcements for IP multimedia subsystem supplementary services

Also Published As

Publication number Publication date
KR101378217B1 (ko) 2014-03-27
KR20080031141A (ko) 2008-04-08
WO2008041830A8 (fr) 2008-10-16

Similar Documents

Publication Publication Date Title
KR101511469B1 (ko) 프레즌스 속성 기반의 프레즌스 통지 시스템 및 방법
US9794356B2 (en) Policy management
EP2153627B1 (fr) Système et procédé d'utilisation de données de présence
EP1550337B1 (fr) Système de communication
Rosenberg et al. An invite-initiated dialog event package for the session initiation protocol (sip)
US20100094952A1 (en) Method and Apparatus for Notifying Clients in a Communication Network
US8185094B2 (en) Message handling in an IP multimedia subsystem
RU2477014C2 (ru) Способ группового оповещения в службе обмена сообщениями на основе протокола инициации сеанса связи "sip"
AU2009215232A1 (en) Method for a session initiation protocol push-to-talk terminal to indicate answer operating mode to an internet protocol push-to-talk network server
KR101492627B1 (ko) 위임 프레즌스 구독을 위한 시스템 및 방법
WO2004086722A1 (fr) Procedes et appareils de demande d'un service au nom d'un tiers
US9325801B2 (en) Method and system for content level reactive authorization
WO2008041830A1 (fr) Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence
US8484298B2 (en) Method and system for SIP based dynamic advertisement of presence information
US9571563B2 (en) Handling a shared data object in a communication network
EP2140664B1 (fr) Procédé et appareil destinés à être utilisés dans un réseau de communications
EP2245824A1 (fr) Procédé d'autorisation d'un observateur par la fourniture d'informations spécifiques à la présentité
Wang et al. A study on session setup for group communications in push-to-talk over cellular using rich presence
Huh et al. The design of presence information management mechanism for IMPP services based on SIP
Huh et al. Design Considerations on Subscription and Notification Function in the Presence Services for Hierarchical ResourceList
Camarillo et al. RFC 5367: Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
GB2443008A (en) Group management in a Session Initiation Protocol network.

Legal Events

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

Ref document number: 07833165

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07833165

Country of ref document: EP

Kind code of ref document: A1