|
List Info
Thread: Re: Progression of draft-polk-sip-rph-in-responses-00
|
|
| Re: Progression of
draft-polk-sip-rph-in-responses-00 |
 
United States |
2007-09-24 13:20:15 |
|
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 <dean.willis softarmor.com> wrote
on 09/24/2007 01:12:49 PM:
> Janet P Gunn wrote:
> > Jeroen van Bemmel <jbemmelzonnet.nl> 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
|
| RE: Progression of
draft-polk-sip-rph-in-responses-00 |
 
Ireland |
2007-09-25 01:29:48 |
|
| 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
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
<dean.willissoftarmor.com> wrote on 09/24/2007 01:12:49 PM:
>
Janet P Gunn wrote:
>; > Jeroen van Bemmel <jbemmelzonnet.nl>
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
|
[1-2]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|