Understand the reasoning behind notify in the first notify for a subscribe but for a refresh we should have put the ability in rfc 3265 to send only a confirmation (e.g. empty notify) that will not load the network and will not require the presence server to get the presence information from the whatever repository it is using.
Avshalom "Brett Tate" <[EMAIL PROTECTED]> 20-02-06 10:39 PM To Avshalom Houri/Haifa/[EMAIL PROTECTED], <[email protected]> cc Subject RE: [Sip-implementors] Delaying NOTIFY on SUBSCRIBE refreshes [RESEND] > I wonder how implementations understand the following from RFC 3265: > > 3.1.6.2. Confirmation of Subscription Creation/Refreshing > > Upon successfully accepting or refreshing a subscription, > notifiers MUST send a NOTIFY message immediately to > communicate the current resource state to the subscriber. > This NOTIFY message is sent on the same dialog as created by > the SUBSCRIBE response. If the resource has no meaningful > state at the time that the SUBSCRIBE message is processed, > this NOTIFY message MAY contain an empty or neutral body. See > section 3.2.2. for further details on NOTIFY message generation. > > What is the definition of *immediately* here? The following are the main purposes of the immediate NOTIFY: 1) create a dialog 2) indicate new subscription state and expiration 3) provide related event package data For most packages and situations, it is acceptable to have a delay of a few seconds when unavoidable. > Will implementations be broken if the server will wait > with the NOTIFY or subscribe refreshes? Typically no if you start trying to deliver the NOTIFY within a few seconds. However it depends upon the importance of having a realtime creation/extension of the dialog and realtime refresh of the package data. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
