Janet,
If there really is a need for the callee to jack up the priority of a
dialog (I don't have a view on that), then a mechanism similar to
connected-identity should be used, i.e., a mid-dialog request in the
reverse direction, which can therefore be challenged and authenticated
in the normal manner.
John
________________________________
From: Janet P Gunn [mailto:[EMAIL PROTECTED]
Sent: 24 September 2007 19:20
To: Dean Willis
Cc: [email protected]; DRAGE, Keith (Keith)
Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
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
