This specification defines the ability to sign the SIP 'Resource-Priority' header field namespace for local emergency communications defined in [RFC 7135
] and represented by the string "esnet.x", where x is the priority level allowed in the esnet namespace. As of the writing of this specification, the priority level is between 0 and 4, inclusive, but may be extended by future specifications.
Similar to the values defined by [RFC 8443
] for the "auth" JSON object key inside the "rph" claim, the string "esnet.x" with the appropriate value should be used when resource priority is required for local emergency communications corresponding and exactly matching the SIP 'Resource-Priority' header field representing the namespace invoked in the call.
When using "esnet.x" as the "auth" assertion value in emergency-service-destined calls, the "orig" claim of the PASSporT MUST
represent the calling party number that initiates the call to emergency services. The "dest" claim MUST
be either a country- or region-specific dial string (e.g., "911" for North America or a "112" GSM-defined string used in Europe and other countries) or "urn:service:sos", as defined in [RFC 5031
], representing the emergency services destination of the call.
The following is an example of an "rph" claim for the SIP 'Resource-Priority' header field with an "esnet.1" assertion:
For emergency services callbacks, the "orig" claim of the "rph" PASSporT MUST
represent the Public Safety Answering Point (PSAP) telephone number. The "dest" claim MUST
be the telephone number representing the original calling party of the emergency service call that is being called back.
The following is an example of an "rph" claim for the SIP 'Resource-Priority' header field with an "esnet.0" assertion:
After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [RFC 8225
], using the full form of PASSporT. The credentials (i.e., Certificate) used to create the signature must have authority over the namespace of the "rph" claim, and there is only one authority per claim. The authority MUST
use its credentials associated with the specific service supported by the resource priority namespace in the claim. If r-values are added or dropped by the intermediaries along the path, the intermediaries must generate a new "rph" identity header and sign the claim with their own authority.