2008
DOI: 10.17487/rfc5263
|View full text |Cite
|
Sign up to set email alerts
|

Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
7
0

Year Published

2008
2008
2016
2016

Publication Types

Select...
6
2

Relationship

1
7

Authors

Journals

citations
Cited by 18 publications
(8 citation statements)
references
References 10 publications
0
7
0
Order By: Relevance
“…Studies with WSNs being used to feed DSSs with input are described in [48] [49]. However, these studies do not take into account belief-rule-based DSSs and the use of heterogeneous wireless sensor networking technologies to the potential being possible today.…”
Section: Impacts Of Belief-rule-based Expert Systemsmentioning
confidence: 99%
“…Studies with WSNs being used to feed DSSs with input are described in [48] [49]. However, these studies do not take into account belief-rule-based DSSs and the use of heterogeneous wireless sensor networking technologies to the potential being possible today.…”
Section: Impacts Of Belief-rule-based Expert Systemsmentioning
confidence: 99%
“…In the SIMPLE framework, there are three techniques that subscribers can apply for reducing inter-domain presence traffic on the network core: partial notifications of presence [17], event notification filtering [18], notification rate control [19] and conditional notifications [20]. An IETF Internet-Draft [21] defines new event filters for location information based on movement, speed, entering or exiting a region, changes in address labels and types of location.…”
Section: Related Workmentioning
confidence: 99%
“…This means that all messages MUST successfully be transferred or the document will become out of sync, and then patches will most likely fail (or worse, have unintended consequences). This "xcap-diff" event package requires, similar to Partial-PIDF-Notify RFC 5263 [RFC5263], that a notifier MUST NOT send a new NOTIFY request to the same dialog unless a successful 200-response has been received for the last sent NOTIFY request. If the NOTIFY request fails due to a timeout, the notifier MUST remove the subscription.…”
Section: Urpalainen and Willis Standards Track [Page 10]mentioning
confidence: 99%