Those are valid concerns. I said that I was oversimplifying, and some of the oversimplification involves mechanisms to addresses some of those concerns.
But we DO need to allow the situation where the first "hop" of a "priority" call does not have RPH, but RPH is added for later hops. Janet Dean Willis <[EMAIL PROTECTED]> wrote on 09/24/2007 01:12:49 PM: > Janet P Gunn wrote: > > Jeroen van Bemmel <[EMAIL PROTECTED]> wrote on 09/21/2007 03:19:09 PM: > > > >> Tim, Brian, > >> > >> First of all a question to clarify the requirements further: is it > >> possible/valid for the request to have no specific priority while its > >> response does, or should the RPH headers in a response always be the > >> same or a subset of those in the request (i.e. copied)? I assume the > > latter > > No, not a valid assumption. > > > > In order to support legacy applications, priority markings (e.g. RPH) may > > be set based on the "dialed number"- e.g., by parsing the Request URI. > > > > In some architectures (e.g. IMS) there may be RPH-capable SIP actors (Type > > A) which do not parse the Request URI looking for the key strings. Such a > > SIP actor would send a SIP Invite WITHOUT RPH. However, a subsequent > > RPH-capable SIP actor (which DOES parse the Request URI looking for the > > key strings) (Type B) would set RPH, both in Invites sent forward, and in > > responses sent back. > > > > So the "Type A" SIP actor could send out an Invite without RPH, but get > > back a response WITH RPH. > > > > I have oversimplified, but the point is that it is not a valid assumption. > > > > Ok, so what keeps me as a Joe End User from putting a "higher priority > than the president" marking on every response I send? You can't > challenge a response or send me an error code if you don't like my > priority. Does every response require authentication of priority level? > > Do we also have a new requirement for a node to "learn" the priority > level of a dialog from a response, and then include that priority level > in future requests on that dialog? > > It seems like this mechanism could be used to "jack up" the priority > level of a dialog: > > 1) Alice sends a low priority request to Bob. > 2) Bob replies with a high-priority marking in the response. > 3) Alice marks all future requests and responses in this dialog high > priority. > > -- > 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
