Summary

  • RFC8599 requires a SIP proxy to periodically generate a new private registration reference, including when the underlying push coordinates have not changed. It also requires keeping older values while associated dialogs remain ongoing.
  • The reference is unique within the proxy's context, not a global device identity. Per-dialog user-agent choice, the dialog route, valid registration information and the push service's own authorization remain separate boundaries.
  • The useful governance principle is limited disclosure with continuing local responsibility: replace what future counterparties see without abandoning the dependencies that existing conversations still have.

The older conversation is the difficult one

Consider a handset that establishes a SIP dialog while its serving proxy supplies one opaque push reference. Later, the handset registers again and receives another reference. A new conversation can advertise the new value. An already established conversation may still direct a subsequent request using the earlier value. These are illustrative events, not an observed operator incident. They expose a problem that a successful test of the latest registration alone would miss.

The proxy can look impeccably current. It recognizes the latest reference, stores usable push information and accepts new dialogs. Yet an older conversation could be stranded if its earlier reference has been erased. The failure is not that the handset has failed to adopt the latest identifier. The mistake is treating issuance of that identifier as evidence that every dependency on the previous one has ended.

RFC8599, published in May2019, addresses push notification for SIP user agents that may not remain continuously available to receive signaling. Its long-lived-dialog provisions contain an unusually revealing pair of obligations. The proxy must periodically generate a new Proxy Unique Registration Reference, or PURR, even when the push parameters are unchanged. At the same time, it must retain old PURR values for as long as the dialogs associated with them remain ongoing. Privacy-driven change and service continuity are simultaneous duties.

That is a stronger idea than routine advice to rotate a credential. It distinguishes what should be newly exposed from what must remain locally resolvable. An old reference can cease to be the preferred value for future dialog setup without ceasing to matter to an earlier dialog. A change in presentation is not, by itself, a change in the life of the obligation behind it.

Why SIP needs a private indirection

A mobile application can be suspended even while its SIP registration remains meaningful. A proxy cannot assume that an existing transport connection will always carry a request to the application. RFC8599 introduces a push-assisted sequence: the proxy requests notification through a Push Notification Service, the user agent wakes and refreshes registration, and signaling can then reach it through the refreshed registration machinery. The push notification is not the SIP request itself.

The user agent obtains a Push Resource ID, or PRID, from its chosen push service. Along with the provider and, where required, another provider-specific parameter, that information allows the proxy to request a notification. The RFC leaves discovery, registration and maintenance of the particular push service to that service's arrangements. It does not create a universal provider account or define a common global lifetime for every provider's resource.

Those coordinates are not suitable information to distribute indiscriminately to a conversational peer. The user agent must not include the push-related URI parameters in non-REGISTER requests, with the explicit exception of pn-purr. The registration request provides the serving network with the information it needs; the peer should receive a restricted reference rather than the private provider coordinates.

PURR supplies that indirection. The proxy generates a value unique within its own context and uses it to retrieve the stored information required to request push. The value must be unforgeable, anonymous and unlinkable to entities other than the proxy. A sufficiently large securely generated random value is a possible approach, but the standard does not appoint one compulsory storage or generation algorithm for every deployment.

These properties are deliberately scoped. The responsible proxy can make the association; otherwise the mechanism would not function. The requirements concerning the value do not prove that all SIP headers, application behavior or operational logs are anonymous. They also do not transform the reference into a globally routable user identity. RFC5627's Globally Routable UA URI serves a different purpose: routing to a particular user-agent instance.

The distinction matters commercially as well as technically. An implementation can promise that its outward-facing references are difficult to correlate while still keeping tightly controlled internal associations needed to serve active conversations. It should not promise that issuing fresh references makes every trace of a conversation disappear. Privacy language becomes misleading when it erases the difference between reducing disclosure and terminating service state.

The user agent opts in one dialog at a time

Support at the proxy does not make every conversation an automatic participant. RFC8599 places the choice with the user agent's local policy. The application can decide whether a particular dialog should support push-assisted delivery of incoming mid-dialog requests, potentially considering characteristics of that dialog or its media. A second dialog is a second policy decision, not merely another transaction under a permanent device-wide approval.

When the user agent elects to use the mechanism, it places a pn-purr parameter in the relevant initial Contact, using the most recently received sip.pnspurr indicator value. If it has not received the supporting indicator, it must not invent the parameter. The peer is being given a reference advertised by the responsible proxy, not an application-created claim that some unspecified intermediary can wake the device.

RFC6809 explains the Feature-Caps setting in which such indicators appear: features of entities not represented by the Contact URI need a way to declare their capabilities. The IANA description of sip.pnspurr concerns association of mid-dialog signaling with registration information. Neither that description nor possession of the reference grants unrestricted rights over the application, its media or its push-service account.

This is why the mechanism cannot sensibly be reduced to a transferable permission token. Several conditions have to coincide. The user agent has selected the mechanism for the dialog. The request follows the applicable dialog routing. The proxy can resolve the reference. The registration and provider arrangements remain usable. Each condition contributes something different; one does not swallow the others.

A local application policy can therefore decline push assistance for one type of dialog without asking a global institution to classify every session. Conversely, an operator cannot claim that provider acceptance of a push request proves the application's dialog policy was correctly applied. Provider admission and user-agent choice operate at different surfaces.

Rotation does not rewrite every existing dependency

For clarity, call an earlier reference P1 and a later one P2. These labels are invented explanatory names, not packet captures or executable wire examples. A dialog established using P1 can still depend on that value after the proxy issues P2. A later registration response supplies the latest reference, but its existence does not demonstrate that every established dialog has replaced the contact information it previously learned.

The two normative duties consequently address different audiences. Fresh reference generation limits the ability of outside observers to correlate an unchanged outward reference over time. Retention ensures that the proxy can still resolve references on which existing dialogs depend. The party allowed to make the private association is also the party required to preserve the necessary continuity.

Keeping P1 is not a command to keep every value forever. The obligation is connected to ongoing dialogs associated with the old reference. Nor does the standard prescribe a universal rotation period or a fixed number of hours after which all old references can be discarded. A housekeeping deadline chosen for convenience is not evidence that the dependent dialog has ended.

There are practical consequences for capacity planning. Counting current registrations alone may not describe the state that has to remain available. The relationship between reference issuance, dialog duration and dependency cleanup can matter. That is an inference about operations, not a measured fleet requirement or an RFC-mandated data structure. A design has to show how it preserves its obligations, not how closely its database resembles someone else's.

It also changes how replacement work should be assessed. Moving a dialog-serving proxy, replacing a lookup store or changing a shard boundary can affect older associations even when the latest registration is reproduced correctly. RFC8599 does not supply a universal replication or proxy-migration protocol. The operator's local implementation must account for the surviving dependency rather than claiming that adoption of the standard solves handover automatically.

The route must still reach the responsible proxy

A stored association is useless if subsequent signaling bypasses the intermediary that can resolve it. Under the applicable dialog-setup procedures, the supporting proxy Record-Routes itself so that it remains in the path of later dialog requests. RFC3261's dialog route set and remote target provide the surrounding SIP architecture. A PURR is not a substitute for that architecture.

Registration routing is a related but different matter. RFC3327's Path extension records intermediaries relevant to reaching a registered user agent. Dialog Record-Route concerns the path retained for an established dialog. Conflating them can produce a convincing diagram with the wrong persistence assumptions: learning a registration path does not by itself prove that a later in-dialog request will visit the PURR-holding proxy.

Transport continuity is another separate problem. RFC5626 describes flows established by the user agent, keep-alive behavior and multiple connections. Those mechanisms address reachability constraints involving NATs, firewalls and connections. Push-assisted waking addresses another condition: the application may need to become available again. An open-looking binding, a remembered dialog route and a deliverable notification should not be treated as interchangeable evidence.

For supported mid-dialog handling, pn-purr can be carried in the Request-URI or a Route URI, depending on construction of the route set. The proxy retrieves the stored information, holds the request in the SIP Request Push Bucket and requests a notification. When it receives the relevant registration transaction's2xx response, it forwards the associated mid-dialog request.

The association rule here is important. The proxy does not apply the initial-request URI comparison from RFC8599 §5.3, because the mid-dialog request does not contain the private pn-prid, pn-provider and pn-param coordinates. It checks for the mid-dialog request carrying the PURR associated with the registration response. The indirection has a real processing consequence; it is not decorative concealment around an otherwise unchanged lookup.

This account is specifically about the mid-dialog procedure. The RFC's initial-request handling includes its own conditions and transport-dependent sequencing. It would be inaccurate to generalize this description into a claim that every SIP request must always await a registration2xx before anything can reach the user agent.

Retention is not an exception to termination

Older references remaining useful does not mean that the underlying registration can never expire. RFC8599 requires the proxy to stop requesting push with the relevant PRID once it is informed that the binding has expired or been removed. An active-dialog association is not a license to revive a removed binding, repair an invalid provider subscription by assumption or ignore a withdrawal of provider authority.

The held request has a boundary too. Waiting for a notification and a registration response does not suspend the sender's transaction lifetime indefinitely. The specification explicitly warns about that timeout and recommends selecting an error response that affects the request transaction rather than unnecessarily damaging the dialog. Continuity is an obligation to handle the dependency correctly, not a guarantee that every attempt will succeed.

The push service remains its own security domain. RFC8599 leaves the particular service's authentication and authorization to its specification; it also requires protected SIP signaling and careful containment of push-related parameters. Registration-event notifications are another possible disclosure path, so merely hiding private coordinates from an initial conversational Contact is not the whole protection story.

RFC8030 documents HTTP Web Push security, including protection of communications and payload considerations. It does not decide the SIP application's per-dialog policy. A provider accepting a request, a proxy locating a reference and a peer having an established dialog are distinct facts. Treating them as one all-purpose authorization obscures which party must answer when the device is disturbed unnecessarily.

What implementation evidence actually establishes

The pinned OpenSIPS3.6 registrar documentation describes support for long-lived-dialog push through pn_enable_purr and pn_process_purr, together with a configurable pn_refresh_timeout. Its explanation makes the operational surfaces tangible: enabling a capability, locating a reference and holding a request have to work together. The documentation is not a measurement of any operator's installed system.

The2020 OpenSIPS support articles provide historical implementation explanation of registration refresh and mid-dialog handling. They are useful evidence that these distinctions have practical implementation expressions. They do not establish that a current cluster retains every required older association, transfers it between nodes or satisfies an operator's claimed privacy properties.

Even small terminology corrections deserve careful sourcing. Verified Editorial erratum8136 corrects sip.pnsreq to sip.pnsreg in RFC8599 §4.1.4. Reported Technical erratum7136 concerns REGISTER Request-URI examples; its reported status is not an accepted normative revision. Neither record justifies inventing a new protocol rule or publishing an example as though it had been tested here.

The conclusion is therefore narrow but substantive. Rotation should reduce the usefulness of exposed references for correlation. It must not cause the responsible proxy to forget ongoing dialogs that still use earlier values. The governing boundary lies in a small common interface and the preservation of its local dependencies, not in a global permission office that approves every subsequent conversation.

Sources