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
