Push Notification with the Session Initiation Protocol (SIP)
Extracted elements (29)
Mid-dialog SIP requests do not carry 'pn-*' URI parameters (which are only in registrar Contact URIs), so a separate mechanism — the PURR stored by the proxy at registration time — is required to map an incoming mid-dialog request to the UA's PRID and trigger push notification.
The mechanism inherently delays the final response to any non-INVITE request requiring a push notification. As discussed in RFC 4320 and RFC 4321, non-INVITE transactions must complete quickly to avoid state misalignment; the Bucket Timer must be set short enough that the error response reaches the sender before the transaction times out at the UAC.
The proxy waits for a 2xx response to the REGISTER request before forwarding a pending SIP request to the UA. This ensures the REGISTER was accepted by the registrar and that the UA is authorized to receive messages for the Request-URI, preventing unauthorized delivery.
A UA that supports both timer-based and push-based binding refresh MUST still send a binding-refresh REGISTER upon receiving a push notification, even if it has already refreshed via a timer. Push notifications for incoming SIP requests are always sent regardless of the non-push capability.
When comparing the Contact URI of a REGISTER 2xx response to Request-URIs in the SIP Request Push Bucket, the proxy uses standard RFC 3261 URI comparison rules augmented to require that 'pn-prid', 'pn-provider', and 'pn-param' also match. If a 'pn-*' parameter is in one URI but not the other, the URIs do not match.
A SIP proxy MUST use a separate Feature-Caps header field for each supported type of PNS. Feature-capability indicators for additional features (e.g., 'sip.vapid') MUST only be inserted in a Feature-Caps header field that also contains a 'sip.pns' indicator.
A UA MUST NOT insert the SIP URI parameters defined in this specification (except 'pn-purr') in non-REGISTER requests, to prevent PNS information associated with the UA from reaching the remote peer. For example, the UA MUST NOT insert 'pn-prid' in the Contact header field URI of an INVITE request.
After a push notification has been requested, if the proxy does not receive a matching REGISTER response before the Bucket Timer times out, the proxy MUST remove the SIP request from the SIP Request Push Bucket and send a 480 (Temporarily Unavailable) response.
If a UA has created multiple bindings, it MUST send a binding-refresh REGISTER request for each binding when it receives a push notification. This ensures all bindings remain active after the UA is awakened.
If a UA is able to send binding-refresh REGISTER requests using a non-push mechanism (e.g., an internal timer), the UA MUST insert a 'sip.pnsreg' media feature tag in the Contact header field of each REGISTER request to inform the proxy.
If the proxy receives information that a binding associated with a PRID has expired or been removed, the proxy MUST NOT request that further push notifications are sent to the UA using that PRID.
If the UA is willing to receive push notifications for mid-dialog requests, the UA MUST insert a 'pn-purr' SIP URI parameter in the Contact header of the initial dialog request, with a value identical to the last 'sip.pnspurr' indicator received in a REGISTER response. If no such indicator was received, the UA MUST NOT insert 'pn-purr'.
It is RECOMMENDED that the proxy requests a push notification at least 120 seconds before the binding expires, to ensure that the associated binding-refresh REGISTER request reaches the registrar before expiration.
Operators MUST ensure that SIP signaling is properly secured; TLS MUST be used unless the operators know that the signaling is secured using some other mechanism that provides strong crypto properties.
Operators MUST ensure that the PNS-related SIP URI parameters conveyed in a REGISTER request Contact URI are not sent to other users or to non-trusted network entities. Where the SIP event package for registrations is used, subscriptions MUST be properly authenticated and authorized.
The PURR MUST be generated such that it is unforgeable, anonymous, and unlinkable to entities other than the proxy. It must not be possible for an attacker to generate a valid PURR, associate a PURR with a specific user, or determine when two PURRs correspond to the same user.
To prevent client fingerprinting, the proxy MUST periodically generate a new PURR value even if 'pn-*' parameters did not change. However, while ongoing dialogs are associated with the old value, the proxy MUST store the old value to support mid-dialog push requests.
To request push notifications from the SIP network, the UA MUST insert 'pn-provider', 'pn-prid', and 'pn-param' (if required for the specific PNS) SIP URI parameters in the Contact header field URI of the REGISTER request.
When a UA receives a push notification, it MUST send a binding-refresh REGISTER request and MUST insert the same set of 'pn-*' SIP URI parameters that it inserted when it originally requested push notifications. If the PNS updated the PRID, the UA inserts the new value.
Four new SIP feature-capability indicators are defined: 'sip.pns' (proxy supports a given PNS type), 'sip.vapid' (proxy supports VAPID for push authentication), 'sip.pnsreg' (proxy expects periodic binding-refresh REGISTERs without push, value is minimum lead time in seconds), and 'sip.pnspurr' (proxy will store PRID keyed by PURR for mid-dialog push).
Four new SIP URI parameters are defined: 'pn-provider' (identifies PNS type), 'pn-prid' (the Push Resource ID), 'pn-param' (PNS-specific auxiliary parameters, e.g., APNs Team ID and Topic), and 'pn-purr' (Proxy Unique Registration Reference for mid-dialog push support). All are carried in Contact header field URIs of REGISTER requests.
The 555 (Push Notification Service Not Supported) SIP response code is introduced. It is only used for REGISTER responses and indicates that the server does not support the push notification service identified in the 'pn-provider' URI parameter.
The Push Resource ID (PRID) is a unique value assigned by the PNS to a UA upon registration. It is carried in the 'pn-prid' SIP URI parameter of REGISTER requests and is used by the SIP proxy to address push notification requests to the correct UA. Its format is PNS-specific.
The SIP Request Push Bucket is a proxy-side store for pending SIP requests (new dialog or standalone) that triggered a push notification. A per-request Bucket Timer governs how long the proxy waits for the UA's binding-refresh REGISTER before sending a 480 error. Requests are removed on REGISTER match, error response, or timer expiry.
A new 'PNS' subregistry is created under the SIP Parameters registry. It holds 'pn-provider' values with 'Specification Required' policy. Initial entries: 'apns' (Apple Push Notification service), 'fcm' (Firebase Cloud Messaging), and 'webpush' (Generic Event Delivery Using HTTP Push per RFC 8030).
Four new SIP URI parameters are registered in the 'SIP/SIPS URI Parameters' subregistry: pn-provider, pn-param, pn-prid, and pn-purr. The 555 response code is registered in the 'Response Codes' subregistry. Four feature-capability indicators (sip.pns, sip.vapid, sip.pnsreg, sip.pnspurr) and one media feature tag (sip.pnsreg) are registered in the SIP Parameters registry.
If a malicious endpoint or network entity obtains the 'pn-*' parameters from SIP signaling, it can request unsolicited push notifications to the UA. Such notifications degrade battery life and trigger unnecessary SIP traffic. The VAPID mechanism (RFC 8292) allows a proxy to sign a JWT so the UA can restrict push notifications to a known proxy public key.
PNS-related SIP URI parameters in REGISTER Contact URIs are sensitive; if forwarded via the SIP event package for registrations (RFC 3680), operators must ensure subscriptions are authenticated and authorized, and that parameters are not included in event notifications sent to other users or untrusted entities.
The SIP URI parameters are encoded as pvalue tokens in the SIP URI parameter syntax (RFC 3261). ABNF: uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr; pn-provider = "pn-provider" [EQUAL pvalue]; pn-prid = "pn-prid" EQUAL pvalue; pn-param = "pn-param" EQUAL pvalue; pn-purr = "pn-purr" EQUAL pvalue. Characters outside pvalue must be percent-escaped.