Hello, Agreed. In addition, not having the RPH in the responses would mean the proxies would have to maintain the state of the RPH value. Martin
________________________________ From: Janet P Gunn [mailto:[EMAIL PROTECTED] In working on specifying and deploying systems that will actually use the RPH with the ets and wps namespaces, we have found several contexts in which the RPH on the response is very useful. 1) Error reporting. RFC 4412 does not give clear direction on the treatment of RPH with syntax errors (out of range priority values, duplicate namespaces, etc.) We have found that including the RPH in the 4xx responses is usesful in addressing the errors. 2) In our system, we often set the ets RPH (with default priority) based on the "ETS-DN""dialed number" or uri, before authentication and before knowing the correct priority value. Including the RPH in the response is a useful way of conveying the correct priority value back to nodes earlier in the "call flow". 3) Similarly, if an RP actor receives a SIP INVITE with the ETS-DN, but no RPH it may, after authenticating the call, include RPH in the responses in order to inform nodes earlier in the call flow that this is a priority call. 4) If the RPH is being used to prioritize processing (of both messages and responses) in the SIP user agent, including the RPH in the response allows the receiving RP actor to give the response "ETS treatment" before checking on the "state" of the call. This is particularly relevant when the RP actor itself is congested. Janet
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
