5.  SIP Proxy Behavior

5.1.  PNS Provider

   The type of PNS is identified by the 'pn-provider' SIP URI parameter.
   In some cases, there might only be one PNS provider for a given type
   of PNS, while in other cases there might be multiple providers.  The
   'pn-param' SIP URI parameter will provide more details associated
   with the actual PNS provider to be used.

   The protocol and format used for the push notification requests are
   PNS-specific, and the details for constructing and sending a push
   notification request are outside the scope of this specification.

5.2.  SIP Request Push Bucket

   When a SIP proxy receives a SIP request addressed towards a UA, that
   will trigger the proxy to request that a push notification be sent to
   the UA.  The proxy will place the request in storage (referred to as
   the SIP Request Push Bucket) and the proxy will start a timer
   (referred to as the Bucket Timer) associated with the transaction.  A
   SIP request is removed from the bucket when one of the following has
   occurred: the proxy forwards the request towards the UA, the proxy
   sends an error response to the request, or the Bucket Timer times
   out.  The detailed procedures are described in the sections below.

   Exactly how the SIP Request Push Bucket is implemented is outside the
   scope of this document.  One option is to use the PRID as a key to
   search for SIP requests in the bucket.  Note that mid-dialog requests
   (Section 6) do not carry the PRID in the SIP request itself.

5.3.  SIP URI Comparison Rules

   By default, a SIP proxy uses the URI comparison rules defined in
   [RFC3261].  However, when a SIP proxy compares the Contact header
   field URI of a 2xx response to a REGISTER request with a Request-URI
   of a SIP request in the SIP Request Push Bucket (Section 5.2), the
   proxy uses the URI comparison rules with the following additions: the
   'pn-prid', 'pn-provider', and 'pn-param' SIP URI parameters MUST also
   match.  If a 'pn-*' parameter is present in one of the compared URIs
   but not in the other URI, there is no match.

   If only the 'pn-*' SIP URI parameters listed above match, but other
   parts of the compared URIs do not match, a proxy MAY still consider
   the comparison successful based on local policy.  This can occur in a
   race condition when the proxy compares the Contact header field URI
   of a 2xx response to a REGISTER request with a Request-URI of a SIP
   request in the SIP Request Push Bucket (Section 5.2) if the UA had
   modified some parts of the Contact header field URI in the REGISTER
   request but the Request-URI of the SIP request in the SIP Request
   Push Bucket still contains the old parts.

5.4.  Indicate Support of Type of PNS

   A SIP proxy uses feature-capability indicators [RFC6809] to indicate
   support of types of PNSs and additional features (e.g., VAPID)
   associated with the type of PNS.  A proxy MUST use a separate
   Feature-Cap header field for each supported type of PNS.  A feature-

   capability indicator that indicates support of an additional feature
   associated with a given type of PNS MUST be inserted in the same
   Feature-Caps header field that is used to indicate support of the
   type of PNS.

   This specification defines the following feature-capability
   indicators that a proxy can use to indicate support of additional
   features associated with a given type of PNS: 'sip.vapid',
   'sip.pnsreg', and 'sip.pnspurr'.  These feature-capability indicators
   MUST only be inserted in a Feature-Caps header field that also
   contains a 'sip.pns' feature-capability indicator.

5.5.  Trigger Periodic Binding Refresh

   In order to request that a push notification be sent to a SIP UA, a
   SIP proxy needs to have information about when a binding will expire.
   The proxy needs to be able to retrieve the information from the
   registrar using some mechanism or run its own registration timers.
   Such mechanisms are outside the scope of this document but could be
   implemented, e.g., by using the SIP event package for registrations
   mechanism [RFC3680].

   When the proxy receives an indication that the UA needs to send a
   binding-refresh REGISTER request, the proxy will request that a push
   notification be sent to the UA.

   Note that the push notification needs to be requested early enough
   for the associated binding-refresh REGISTER request to reach the
   registrar before the binding expires.  It is RECOMMENDED that the
   proxy requests the push notification at least 120 seconds before the
   binding expires.

   If the UA has indicated, using the 'sip.pnsreg' media feature tag,
   that it is able to wake itself using a non-push mechanism in order to
   send binding-refresh REGISTER requests, and if the proxy does not
   receive a REGISTER request prior to 120 seconds before the binding
   expires, the proxy MAY request that a push notification be sent to
   the UA to trigger the UA to send a binding-refresh REGISTER request.

   NOTE: As described in Section 4.1.5, a UA might send a REGISTER
   request without including a 'pn-prid' SIP URI parameter in order to
   retrieve push notification capabilities from the network before the
   UA expects to receive push notifications from the network.  A proxy
   will not request that push notifications are sent to a UA that has
   not provided a 'pn-prid' SIP URI parameter (Section 5.6.2).

   If the proxy receives information that a binding associated with a
   PRID has expired, or that a binding has been removed, the proxy MUST
   NOT request that further push notifications are sent to the UA using
   that PRID.

5.6.  SIP Requests

5.6.1.  REGISTER

   This section describes how a SIP proxy processes SIP REGISTER
   requests (initial REGISTER request for a binding or a binding-refresh
   REGISTER request).

   The procedures in this section apply when the REGISTER request
   contains a 'pn-provider' SIP URI parameter in the Contact header
   field URI.  In other cases, the proxy MUST skip the procedures in
   this section and process the REGISTER request using normal SIP
   procedures.

5.6.1.1.  Request Push Notifications

   This section describes the SIP proxy procedures when a SIP UA
   requests push notifications from the SIP network.

   The procedures in this section apply when the SIP REGISTER request
   contains, in addition to the 'pn-provider' SIP URI parameter, a
   'pn-prid' SIP URI parameter in the Contact header field URI of the
   request.

   When a proxy receives a REGISTER request that contains a Feature-Caps
   header field with a 'sip.pns' feature-capability indicator, it
   indicates that another proxy between this proxy and the UA supports
   the type of PNS supported by the UA, and will request that push
   notifications are sent to the UA.  In such case, the proxy MUST skip
   the rest of the procedures in this section and process the REGISTER
   request using normal SIP procedures.

   When a proxy receives a REGISTER request that does not contain a
   Feature-Caps header field with a 'sip.pns' feature-capability
   indicator, the proxy processes the request according to the
   procedures below:

   o  If the proxy does not support the type of PNS supported by the UA,
      or if the REGISTER request does not contain all information
      required for the type of PNS, the proxy SHOULD forward the request
      towards the registrar and skip the rest of the procedures in this
      section.  If the proxy knows (by means of local configuration)
      that no other proxies between itself and the registrar support the

      type of PNS supported by the UA, the proxy MAY send a SIP 555
      (Push Notification Service Not Supported) response instead of
      forwarding the request.

   o  If the proxy supports the type of PNS supported by the UA, but
      considers the requested binding expiration interval [RFC3261] to
      be too short (see below), the proxy MUST either send a 423
      (Interval Too Brief) response to the REGISTER request or forward
      the request towards the registrar and skip the rest of the
      procedures in this section.

   o  If the proxy supports the type of PNS supported by the UA, the
      proxy MUST indicate support of that type of PNS (Section 5.4) in
      the REGISTER request before it forwards the request towards the
      registrar.  This will inform proxies between the proxy and the
      registrar that the proxy supports the type of PNS supported by the
      UA, and that the proxy will request that push notifications are
      sent to the UA.

   A binding expiration interval MUST be considered too short if the
   binding would expire before the proxy can request that a push
   notification be sent to the UA to trigger the UA to send a binding-
   refresh REGISTER request.  The proxy MAY consider the interval too
   short based on its own policy so as to reduce load on the system.

   When a proxy receives a 2xx response to the REGISTER request, if the
   proxy indicated support of a type of PNS in the REGISTER request (see
   above), the proxy performs the following actions:

   o  If the proxy considers the binding expiration interval indicated
      by the registrar too short (see above), the proxy forwards the
      response towards the UA and MUST skip the rest of the procedures
      in this section.

   o  The proxy MUST indicate support of the same type of PNS in the
      REGISTER response.  In addition:

      *  If the proxy supports the VAPID mechanism [RFC8292], the proxy
         MUST indicate support of the mechanism, using the 'sip.vapid'
         feature-capability indicator, in the REGISTER response.  The
         indicator value contains the public key identifying the proxy.
         The proxy MUST determine whether the PNS provider supports the
         VAPID mechanism before it indicates support of it.

      *  If the proxy received a 'sip.pnsreg' media feature tag in the
         REGISTER request, the proxy SHOULD insert a 'sip.pnsreg'
         feature-capability indicator with an indicator value bigger
         than 120 in the response, unless the proxy always wants to
         request that push notifications are sent to the UA in order to
         trigger the UA to send a binding-refresh REGISTER request.

5.6.1.2.  Query Network PNS Capabilities

   This section describes the SIP proxy procedures when a SIP UA queries
   about the push-notification support in the SIP network
   (Section 4.1.5).

   The procedures in this section apply when the REGISTER request
   contains a 'pn-provider' SIP URI parameter, but does not contain a
   'pn-prid' SIP URI parameter in the Contact header field URI of the
   REGISTER request.

   When a proxy receives a REGISTER request that contains a
   'pn-provider' SIP URI parameter indicating the type of PNS supported
   by the UA, the proxy MUST perform the following actions:

   o  If the proxy supports the type of PNS supported by the UA, the
      proxy MUST indicate support of that type of PNS (Section 5.4) in
      the REGISTER request before it forwards the request towards the
      registrar.  This will inform any other proxies between the proxy
      and the registrar that the proxy supports the type of PNS
      supported by the UA.

   o  If the proxy does not support the type of PNS supported by the UA,
      and if the REGISTER request contains Feature-Caps header fields
      indicating support of one or more types of PNSs, the proxy
      forwards the request towards the registrar.

   o  If the proxy does not support the type of PNS supported by the UA,
      and if the REGISTER request does not contain Feature-Caps header
      fields indicating support of one or more types of PNSs, the proxy
      MUST either forward the request towards the registrar or send a
      SIP 555 (Push Notification Service Not Supported) response towards
      the UA.  The proxy MUST NOT send a SIP 555 (Push Notification
      Service Not Supported) response unless it knows (by means of local
      configuration) that no other proxy supports any of the types of
      PNSs supported by the UA.

   When a proxy receives a REGISTER request, and the 'pn-provider' SIP
   URI parameter does not contain a parameter value, the proxy MUST
   indicate support of each type of PNS supported by the proxy before it
   forwards the request towards the registrar.

   When a proxy receives a 2xx response to the REGISTER request, if the
   proxy had indicated support of one or more types of PNSs in the
   REGISTER request (see above), the proxy MUST indicate support of the
   same set of types of PNSs in the response.  In addition, if the proxy
   supports the VAPID mechanism for one or more types of PNSs, the proxy
   MUST indicate support of the mechanism for those PNSs in the
   response.

5.6.2.  Initial Request for Dialog or Standalone Request

   The procedures in this section apply when a SIP proxy has indicated
   that it will request that push notifications are sent to the SIP UA.

   When the proxy receives a SIP request for a new dialog (e.g., a SIP
   INVITE request) or a standalone SIP request (e.g., a SIP MESSAGE
   request) addressed towards a SIP UA, if the Request-URI of the
   request contains a 'pn-provider', a 'pn-prid', and a 'pn-param' (if
   required for the specific PNS provider) SIP URI parameter, the proxy
   requests that a push notification be sent to the UA using the
   information in the 'pn-*' SIP URI parameters.  The proxy then places
   the SIP request in the SIP Request Push Bucket.  The push
   notification will trigger the UA to send a binding-refresh REGISTER
   request that the proxy will process as described in Section 5.6.1.
   In addition, the proxy MUST store the Contact URI of the REGISTER
   request during the lifetime of the REGISTER transaction.

   NOTE: If the proxy receives a SIP request that does not contain the
   'pn-*' SIP URI parameters listed above, the proxy processing of the
   request is based on local policy.  If the proxy also serves requests
   for UAs that do not use the SIP push mechanism, the proxy can forward
   the request towards the UA.  Otherwise, the proxy can reject the
   request.

   When the proxy receives a 2xx response to the REGISTER request, the
   proxy performs the following actions:

   o  The proxy processes the REGISTER response as described in
      Section 5.6.1.

   o  The proxy checks whether the SIP Request Push Bucket contains a
      SIP request associated with the REGISTER transaction by comparing
      (Section 5.3) the Contact header field URI in the REGISTER
      response with the Request-URIs of the SIP requests in the bucket.
      If there is a match, the proxy MUST remove the SIP request from
      the bucket and forward it towards the UA.

   The reason the proxy needs to wait for the REGISTER response before
   forwarding a SIP request towards a UA is to make sure that the
   REGISTER request has been accepted by the registrar, and that the UA
   that initiated the REGISTER request is authorized to receive messages
   for the Request-URI.

   If the proxy receives a non-2xx response to the REGISTER request, the
   proxy compares the Contact URI stored from the REGISTER request (see
   above) with the Request-URIs of the SIP requests in the SIP Request
   Push Bucket.  If there is a match, the proxy SHOULD remove the
   associated request from the bucket and send an error response to the
   request.  It is RECOMMENDED that the proxy sends either a 404 (Not
   Found) response or a 480 (Temporarily Unavailable) response to the
   SIP request, but other response codes can be used as well.  However,
   if the REGISTER response is expected to trigger a new REGISTER
   request from the UA (e.g., if the registrar is requesting the UA to
   perform authentication), the proxy MAY keep the SIP request in the
   bucket.

   If the push notification request fails (see PNS-specific
   documentation for details), the proxy MUST remove the SIP request
   from the bucket and send an error response to the SIP request.  It is
   RECOMMENDED that the proxy sends either a 404 (Not Found) response or
   a 480 (Temporarily Unavailable) response, but other response codes
   can be used as well.

   After the proxy has requested that a push notification be sent to a
   UA, if the proxy does not receive a REGISTER response with a Contact
   URI that matches the Request-URI of the SIP request before the Bucket
   Timer (Section 5.2) associated with the SIP request times out, the
   proxy MUST remove the SIP request from the SIP Request Push Bucket
   (Section 5.2) and send a 480 (Temporarily Unavailable) response.  The
   Bucket Timer time-out value is set based on local policy, taking the
   guidelines below into consideration.

   As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must
   complete immediately or risk losing a race, which results in stress
   on intermediaries and state misalignment at the endpoints.  The
   mechanism defined in this document inherently delays the final
   response to any non-INVITE request that requires a push notification.
   In particular, if the proxy forwards the SIP request towards the SIP
   UA, the SIP UA accepts the request, but the transaction times out at
   the sender before it receives the successful response, this will
   cause state misalignment between the endpoints (the sender considers
   the transaction a failure, while the receiver considers the
   transaction a success).  The SIP proxy needs to take this into
   account when it sets the value of the Bucket Timer associated with
   the transaction, to make sure that the error response (triggered by a

   Bucket Timer time out) reaches the sender before the transaction
   times out.  If the accumulated delay of this mechanism combined with
   any other mechanisms in the path of processing the non-INVITE
   transaction cannot be kept short, this mechanism should not be used.
   For networks encountering such conditions, an alternative (left for
   possible future work) would be for the proxy to immediately return a
   new error code meaning "wait at least the number of seconds specified
   in this response and retry your request" before initiating the push
   notification.

   NOTE: While the work on this document was ongoing, implementation
   test results showed that the time it takes for a proxy to receive the
   REGISTER request, from when the proxy has requested a push
   notification, is typically around 2 seconds.  However, the time might
   vary depending on the characteristics and load of the SIP network and
   the PNS.

   In addition to the procedures described above, there are two cases
   where a proxy, as an optimization, can forward a SIP request towards
   a UA without either waiting for a 2xx response to a REGISTER request
   or requesting that a push notification be sent to the UA:

   o  If the proxy is able to authenticate the sender of the REGISTER
      request and verify that it is allowed by authorization policy, the
      proxy does not need to wait for the 2xx response before it
      forwards the SIP request towards the UA.  In such cases, the proxy
      will use the Contact URI of the REGISTER request when comparing it
      against the Request-URIs of the SIP requests in the SIP Request
      Push Bucket.

   o  If the proxy has knowledge that the UA is awake, and that the UA
      is able to receive the SIP request without first sending a
      binding-refresh REGISTER request, the proxy does not need to
      request that a push notification be sent to the UA (the UA will
      not send a binding-refresh REGISTER request) before it forwards
      the SIP request towards the UA.  The mechanisms for getting such
      knowledge might be dependent on implementation or deployment
      architecture, and are outside the scope of this document.

   Some PNS providers allow payload in the push notifications.  This
   specification does not define usage of such payload (in addition to
   any payload that might be required by the PNS itself).