Module push 

Push notifications (RFC 8599), at the URI and header level.

The problem: a mobile client is not running, or is running with every socket torn down by the operating system. There is no flow to route a call down and no keep-alive that could hold one open, so the registrar’s binding names an address that reaches nothing. RFC 8599’s answer is to route around SIP for one hop — the proxy asks the client’s push notification service to wake it, and the client, once awake, goes and gets a flow.

What lives here is the part that is pure syntax, and it is three separate things that are easy to conflate:

• The pn-* parameters (§8.7) a Contact URI carries, which tell the registrar which push service to ask and how that service names this device. They are URI parameters, so they go inside the angle brackets of a Contact; outside them a ; starts a header parameter and a registrar reading the URI would never see them (RFC 3261 §20).
• The feature-capability indicators (§8.2), which travel in Feature-Caps (RFC 6809) and are how the registrar answers back: which push service it actually supports, whether it wants refreshes anyway, and what it will call this binding.
• 555 (§8.1), the status code that says the client’s whole reachability plan is wrong.

Nothing here sends or receives a push notification. sipx implements the SIP half of RFC 8599 and nothing else — the push service is behind a trait in sipx-ua and this repository ships no implementation of one. Deciding what a registration should say, and reading what came back, belongs in sipx-ua for the same reason crate::gruu’s registration half does.

Structs

Device

How a push notification service names one device (§4.1.2, §8.7).

Indicators

The push feature-capability indicators one Feature-Caps value carries (§8.2).

Constants

NOT_SUPPORTED

555 (Push Notification Service Not Supported), registered in §8.1.

NOT_SUPPORTED_REASON

The reason phrase §8.1 registers alongside NOT_SUPPORTED.

PN_PARAM

The Contact URI parameter carrying whatever else the named service needs (§8.7).

PN_PRID

The Contact URI parameter carrying the identifier the service knows this device by (§8.7).

PN_PROVIDER

The Contact URI parameter naming the push notification service (§8.7).

PN_PURR

The Contact URI parameter carrying the PURR — the Push Resource Reachability Reference the proxy assigned this binding (§8.7).

SIP_PNS

The feature-capability indicator naming a push notification service (§8.2).

SIP_PNSPURR

The feature-capability indicator carrying the PURR assigned to a binding (§8.2).

SIP_PNSREG

The feature-capability indicator asking for binding refreshes even without a push (§8.2).

Functions

is_not_supported

Whether a status is §8.1’s 555.

purr

The PURR a URI carries, if it carries one (§8.7).