In order to explain the use case for the requirements for "RPH in
Responses", we have submitted an Internet Draft.
http://www.ietf.org/internet-drafts/draft-gunn-sip-req-for-rph-in-responses-00.txt
Janet
Janet P Gunn/FED/[EMAIL PROTECTED] wrote on 09/24/2007 02:20:15 PM:
>
>
>
> 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
_______________________________________________
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
