1) IANA registry.
The current IANA registry contents created by RFC 4412 is merely:
Header Name compact Reference
----------------- ------- ---------
Accept-Resource-Priority [RFC4412]
Resource-Priority [RFC4412]
The only IANA registry change required to to add this draft to the
reference against Resource-Priority, and not to do what is currently
listed in section 4.
Additionally statements in section 1:
This document IANA registers the Resource-Priority header for usage
in responses.
And
The above is to replace what is currently stated by RFC 4412, and
what is IANA registered.
Should also be corrected.
2) Section 3.1 of RFC 4412 specifies:
There is no protocol requirement that all requests within a SIP
dialog or session use the 'Resource-Priority' header field. Local
administrative policy MAY mandate the inclusion of the
'Resource-Priority' header field in all requests. Implementations of
this specification MUST allow inclusion to be either by explicit user
request or automatic for all requests.
I assume that the usage of the header in responses is an extension of
the administrative policy stated above, and therefore this linkage needs
to be made. For example, I read the above text to indicate that a
stateful proxy could receive the header in a initial INVITE request, and
treat all requests and responses in the same dialog with priority. In
this case, I therefore do not need the header in subsequent requests,
and equally I don't need it in any responses either.
3) RFC 4412 divides the SIP methods into a set of classes giving
various levels of support. I assume that these classes also apply for
the support of responses, but I can currently find no text that
indicates that.
4) RFC 4412 indicates for example:
A SIP request with a 'Resource-Priority' indication can be treated
differently in these situations:
1. The request can be given elevated priority for access to PSTN
gateway resources, such as trunk circuits.
2. The request can interrupt lower-priority requests at a user
terminal, such as an IP phone.
3. The request can carry information from one multi-level priority
domain in the telephone network (e.g., using the facilities of
Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves
inspecting or modifying the header field.
4. In SIP proxies and back-to-back user agents, requests of higher
priorities may displace existing signaling requests or bypass
PSTN gateway capacity limits in effect for lower priorities.
This also applies equally for the responses discussed in this document.
We probably need some general text that basically says that what RFC
4412 specifies for requests, also applies to responses when implementing
this document. This is both at the requirement level and the discussion
level.
5) Section 2.3 of this document indicates:
SIP Proxies MAY process the Resource-Priority header in responses;
meaning, in certain environments, the choice of whether or not to
process the RPH will not be in doubt.
Section 4.7.3 of RFC 4412 states:
SIP proxies MAY ignore the 'Resource-Priority' header field. SIP
proxies MAY reject any unauthenticated request bearing that header
field.
However, I assume that what 2.3 is attempting to state is not the above
for responses, but rather: Even though the proxy processes the header in
requests, it may ignore the header in responses.
Regards
Keith
_______________________________________________
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
