It seems like there's more motivating draft-polk-sip-rph-in-
responses-00 than just the need to prioritize access to scarce
gateway resources. A lot of the people I've talked to are thinking
that it is also useful for prioritizing message processing in
congested proxies or other SIP nodes (like B2BUAs, call center
queues, whatever).
It has even been suggested that the RPH value might be used by a
congested node for selective discard of responses, which has some
interesting impacts on the overload queueing model.
An unstated goal here is that even if proxy-like resources are
operating at a totally saturated level they MUST still be able to
process messages with a high RPH value, even if it means totally
disrupting lower-priority traffic and creating cascade collapse and
link saturation with message retransmissions. It seems to me that
this would require very careful collaboration with a diffserv layer
to make work, but that's just one of the open questions.
The other open questions I think I see are a) how to allow a
priority determination to be made by a node on the "response" side of
the loop, and b) how to deal with authentication and authorization
for priority levels requested in a response. This raises a couple of
state-management questions, and two big thorny architectural questions.
The state bits are easy, I think -- Having learned of a priority
established "somewhere along the line", each statefully participating
SIP node must continue to add an equivalent priority header in future
messages. Unless of course the node has reason to be changing the
priority level, which of course raises all sorts of questions about
who is allowed to change a value, how we can tell it has been
changed, whether or not we decide to honor the change, and so on.
The more fundamental architectural questions are 1) How do we change
anything in a response that can't be challenged, and 2) how do we
authenticate changes introduced by non-terminal nodes?
The first problem we've traditionally addressed by a reverse-
direction request, as noted by John Elwell. That might work here.
The second problem is a much bigger mess, one that we've categorized
as "middle-to-middle" and/or "middle-to-end". This is a big open
problem in the SIP space, one that we don't even have a charter item
to address. We bogged down on the simpler end-to-middle problem,
which we managed to document as a more-or-less experimental document
pending better understanding of the problem.
Consequently, I think we're asking RPH to do a lot of things for us
that it really can't do in the general case.
The only solution that comes to mind is to simplify the problem
scope. Perhaps if we started from a really concise statement of what
we can reasonably do with a mechanism like RPH, we'd make more
headway in understanding the problem.
A short list to work from:
1) RPH can only be set by a request-originating UA. Consequently, any
intermediary node that is changing RPH MUST be a B2BUA.
2) Like other dialog attributes, changes of RPH require modification
of the dialog via UPDATE or reINVITE.
These two constraints are driven by the request-authentication model
and the like of m2m authentication in SIP.
Given these constraints, can we meed the needs of the community? Now
the "how they want things to work" needs, but the real required
functionality for prioritization?
Do we need to add RPH negotiation to the session-policy mechanism?
--
Dean
_______________________________________________
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
