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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
