Subject: Re: [Sip] Progression of draft-polk-sip-rph-in-responses-00

From: Janet P Gunn <[email-masked]>
Date: Sun, 18 Nov 2007 20:54:29 -0500

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/CSC@CSC 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-masked]> wrote on 09/24/2007 01:12:49 PM:
> 
> > Janet P Gunn wrote:
> > > Jeroen van Bemmel <[email-masked]> 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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip