[Sip] Need for RPH in SIP Responses

It seems to me that the strongest argument for the inclusion of RPH in
SIP responses is illustrated by the following two use cases.

Authentication, authorization and assignment of priority for a GETS/WPS
call happens in the middle of the network, and preceding nodes (between
the caller and the authenticating node)

A)      are initially aware of the GETS/WPS call but they need to know
the priority level assigned to the call after authorization, or

B)      are initially not aware of the GETS/WPS call and they need to
know that the call is authorized as a GETS/WPS call and they also need
to know the priority level assigned to the call after authorization.

The Internet Draft, "Requirements for SIP Resource Priority Header in
SIP Responses" (draft-gunn-sip-req-for-rph-in-responses-00) has
described the use case A).

The Internet Draft, "Allowing SIP Resource Priority Header in SIP
Responses" (draft-polk-sip-rph-in-responses-00) identifies the need for
inclusion of RPH in SIP responses for the benefit of stateless servers
in some environments. This draft proposes that a UAS can optionally
include an RPH in a SIP response. It also proposes that a receiving node
may choose to ignore the RPH. In other words, both the inclusion of the
RPH in responses and processing of the received RPH in responses are
optional capabilities. Nodes and networks can choose not to implement
these capabilities. 

It is critical to get the RPH with the caller's priority level back to
the originating network node after the GETS/WPS call authorization since
this is needed to reserve access (and possibly other) resources
immediately. Radio access resources are very limited, and during
emergency, they are typically congested and not available to the few
first responders that need to place calls. The operation of GETS/WPS is
dependent on the capability of inclusion of RPH in SIP responses.

Regards,

Niranjan Sandesara