Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01

From: "Elwell, John" <[email-masked]>
Date: Wed, 09 Feb 2005 10:13:52 +0000

David,

In-line.

John

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: 08 February 2005 19:25
> To: Paul Kyzivat
> Cc: 'Elwell, John'; 'Joanne McMillen'; Francois Audet; 
> 'Jesske, R'; [email-masked]'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> Paul has really nailed this one. One of the primary purposes for  
> defining request history was to allow us get away from the PSTN/PBX  
> notions of call redirection. 
[JRE] What was the reason for wanting to get away from this notion? This is
what is happening, so why not acknowledge this and give it the name
"redirection" or something else and identify the different types of reason
for this?

> Any voicemail server that can interpret  
> request history can figure out what the right response to an 
> incoming  
> invite is without this.
[JRE] Voicemail is not the only application of history-info. A human user of
a UA that receives history-info in an INVITE request or in a response to an
INVITE request may be able to make use of additional information to help
figure out how to behave.

> 
> On Feb 8, 2005, at 1:23 PM, Paul Kyzivat wrote:
> 
> > I have a problem with the whole notion of "retargetting" - I don't  
> > know how well defined it is.
> >
> > If I have two UAs registered to my AoR, with the same 
> q-value, and a  
> > reqeust is parallel forked to them, then I guess there is no  
> > retargetting.
> >
> > If they have different q-values and a request is serial 
> forked, and  
> > the first fork doesn't answer, is going to the 2nd tine of 
> the fork  
> > retargetting?
> >
> > Same, but the 2nd fork is to a VM server - is that retargetting?
> >
> > Same, but the contact used in the 2nd fork happens to be 
> another AoR,  
> > is that retargetting?
> >
> > If I only have one UA registered to my AoR, and my proxy routes a  
> > request to that UA but it doesn't answer, and then my proxy 
> routes the  
> > request to a VM server using a URI configured into its call 
> handling  
> > script, is that redirection?
> >
> > And do any of these answers change if in some cases proxying is  
> > replaced with a 3xx response?
> >
> > It seems to me that the distinction between "redirection" 
> and "normal  
> > routing" is entirely subjective, and probably depends on who you  
> > imagine will be looking at the result and what you think 
> they will be  
> > doing about it.
> >
> > I am at a loss for naming the distinction when I don't see one.
> >
> > 	Paul
> >
> > Francois Audet wrote:
> >> I believe "Normal" is meant to mean routing the way a 
> redirect server
> >> would do, for "normal routing reasons".
> >> I'm not sure I like the word "Normal" to describe this. 
> But basically,
> >> the idea is to distinguish between "normal routing" and  
> >> "retargetting".
> >> The problem is that in an environment where a redirect 
> server is used
> >> instead of a proxy for "normal" routing, all calls then 
> look like they
> >> are "retargeted".
> >> One example where this is a problem is the voicemail example in  
> >> Appendix
> >> B of draft-ietf-sip-history-info-06.txt. Voicemail systems rely on
> >> knowing if the call was "forwarded/retargeted" or not in 
> order to take
> >> appropriate action.
> >> If you have a better idea for how to call this, please 
> suggest it,  
> >> because
> >> I do think the current term is ambiguous.
> >>  > -----Original Message-----
> >>  > From: [email-masked]
> >>  > [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> >>  > Sent: Tuesday, February 08, 2005 07:48
> >>  > To: Elwell, John
> >>  > Cc: Jesske, R; Joanne McMillen; [email-masked]'
> >>  > Subject: Re: [Sipping] 
> draft-elwell-sipping-redirection-reason-01
> >>  >
> >>  >
> >>  > John,
> >>  >
> >>  > I just took a look at this, and have a couple of questions about
> >>  > specific causes:
> >>  >
> >>  > Cause=1 (Normal redirection - The call has been retargeted for  
> >> normal
> >>  > routing reasons): what is a "normal routing reason"? AFAIK,
> >>  > some or all
> >>  > of the other listed causes are themselves normal 
> routing reasons.
> >>  >
> >>  > Cause=8 (Mobile not reachable): how is this different from
> >>  > causes 2,3,4?
> >>  > If you want this, why not "fixed phone unavailable, video phone
> >>  > unavailable, etc."?
> >>  >
> >>  >       Paul
> >>  >
> >>  > Elwell, John wrote:
> >>  > > This examines the need for signalling additional information
> >>  > > concerning the reason for redirection in SIP and proposes
> >>  > an extension
> >>  > > to the Reason header. In particular it can be used in
> >>  > conjunction with
> >>  > > request history.
> >>  > >
> >>  > > The 01 draft was submitted to address preferences expressed  
> >> during
> >>  > > discussion of the 00 draft. In my opinion the draft is fairly
> >>  > > complete, although obviously the list of initially
> >>  > registered values
> >>  > > for redirection cause codes might be subject to 
> discussion. I  
> >> would
> >>  > > like to ask how the community would wish this to 
> progress. Is  
> >> there
> >>  > > interest in making this a SIPPING work item? Are any
> >>  > changes required?
> >>  > >
> >>  > > John
> >>  > >
> >>  > > _______________________________________________
> >>  > > Sipping mailing list   
> >> https://www1.ietf.org/mailman/listinfo/sipping
> >>  > > This list is for NEW development of the application of SIP Use
> >>  > > [email-masked] for questions on 
> current sip Use
> >>  > > [email-masked] for new developments of core SIP
> >>  > >
> >>  >
> >>  > _______________________________________________
> >>  > Sipping mailing list   
> >> https://www1.ietf.org/mailman/listinfo/sipping
> >>  > This list is for NEW development of the application of SIP
> >>  > Use [email-masked] for questions on current
> >>  > sip Use [email-masked] for new developments of core SIP
> >>  >
> >>  >
> >> 
> --------------------------------------------------------------
> -------- 
> >> --
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP
> >> Use [email-masked] for questions on current sip
> >> Use [email-masked] for new developments of core SIP
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> >
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: [email-masked]
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David R Oran <[email-masked]>
Date: Wed, 9 Feb 2005 08:24:34 -0500

> "redirection" or something else and identify the different types of 
Because of exactly the points Paul raises. It's a distinction without a 
difference - an arbitrary categorization of one of a whole class of 
things that can happen because a URI was rewritten by somebody. If you 
can't figure out what happened by looking at the history, slapping an 
arbitrary value judgment in the reason header by the rewriting entity 
why it thought it was rewriting the URI just opens the door to 
configuration errors. Why can't I have the reason "Happy Hour" in the 
reason header because I have a SIP server that decides to retarget a 
URI to the local bar between 5 and 7 PM?

> figure out how to behave.
I agree with the first part, but not the second. It's the ultimate 
consumer who looks at the history and decides what to do based on what 
happened. You are proposing specifying a particular and very limited 
class of reasons *why* it happened. This requires knowledge in the 
retargeting server that in general it need not have (and probably 
shouldn't).

Dave.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]