(As WG chair)
Dean attempted to get this one started a while back and it fell on stony
ground.
We have now set charter milestones for all the documents we agreed to
progress at the last IETF meeting except for the draft above.
The reason for this absence is that after discussion with the AD, we are
not convinced that doing this provides a significant benefit. Part of
this may be clarified by revising the draft as an author draft but...
The essence of the problem is that the application is to that of a
transaction stateless proxy. Of the list of activities specified by RFC
4412:
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.
The only reason for including a Resource-Priority header in a response
for use in a transaction stateless proxy is item 4 above. This means
that a response for (namespace x, priority 5) could be handled ahead of
a response for (namespace x, priority 4).
The question is what is the impact of such handling on an overloaded
system, where such priority handling could have a benefit (we assume
that in a system that is not overloaded then responses can be pushed
back pretty much as fast as they are received). If a response processing
gets delayed according to some queueing mechanism, then eventually
timers related to the request at the entity before this proxy will time
out, and the request will be repeated. This increases the processing
load on an overloaded system.
So in terms of resource priority, is the appropriate model that
responses should always be handled immediately and before the request
queues are handled, or is there a justification for some other model.
Please respond and tell us we have got it wrong.
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
