[Sip] Need for RPH in SIP Responses

Hi!

The SIP Resource Priority Header (RPH), in its current form, is not
allowed in SIP responses.  This was a design choice during RFC 4412's
development. This is not a good choice in certain scenarios. The
Internet Draft, "Allowing SIP Resource Priority Header in SIP Responses"
(draft-polk-sip-rph-in-responses-00) describes a modification to RFC4412
to permit RPH in responses. The Internet Draft, "Requirements for SIP
Resource Priority Header in SIP Responses"
(draft-gunn-sip-req-for-rph-in-responses-00), describes one of the
requirements associated with systems using RPH, that could be easily met
by the modification of RFC 4412 to permit RPH in responses, and can not
be easily met by other methods. Additional scenarios and requirement are
described below that can be easily met if RPH is permitted in responses
per draft-polk-sip-rph-in-responses-00.

All aspects of a GETS/WPS call require priority treatment in order to
ensure that it is successfully established with priority, maintained
with adequate quality and priority, and released with priority.  RFC
3261 permits stateless servers. There are scenarios involving stateless
servers that require such servers to provide priority treatment to
GETS/WPS calls. Three scenarios are described below where inclusion of
RPH in SIP responses would enable a stateless server to provide priority
treatment.

1.	If there is congestion at a SIP server, it is important that SIP
messages (requests as well as responses) related to a GETS/WPS call are
processed with priority, and discarded last in comparison with normal
calls. Presence of RPH in SIP responses would enable a stateless server
to provide such capability.
2.	A network can mark IP packets that carry SIP messages related to
GETS/WPS calls with a specific DiffServ Code Point (DSCP). This could be
used as one mechanism to ensure that such packets receive priority
treatment in transport through an IP network. A stateless server can
mark IP packets that carry SIP responses in this manner only if it
recognizes the responses that are related to GETS/WPS calls. Presence of
RPH in SIP responses would enable a stateless server to mark packets
carrying SIP responses in this manner or other priority transport
mechanisms (e.g. MPLS path selection). 
3.	On receipt of a SIP response related to a GETS/WPS call, if a
stateless server needs to invoke other services and interact with other
servers with priority, it needs to be aware of the GETS/WPS call.
Presence of RPH in SIP responses would enable a stateless server to
provide such capability.

As described in the internet draft, "Requirements for SIP Resource
Priority Header in SIP Responses"
(draft-gunn-sip-req-for-rph-in-responses-00), GETS/WPS paradigm is
different from the MLPP paradigm. One important difference between the
two is that a GETS/WPS call request from the calling party may not
include an RPH. It is possible that SIP servers (whether stateful or
stateless) preceding the server that authenticates and authorizes a
GETS/WPS call request have RPH capability but do not have the capability
to identify the request as a GETS/WPS call request. After successful
authorization, the authenticating server will insert an RPH in all
requests it sends. In this scenario, the servers preceding the
authenticating servers would not become aware of the priority nature of
the call and would not provide any priority treatment until they receive
a SIP request with an RPH from the authenticating server.  This is not
desirable. This situation can be easily remedied if RPH is permitted in
SIP responses.

As has been pointed out earlier, possible security risk of permitting
RPH in SIP responses is minimal in managed IP networks where this
capability is generally expected to be used. 

Regards,

Niranjan Sandesara