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

From: "Francois Audet" <[email-masked]>
Date: Tue, 8 Feb 2005 12:32:15 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Feb 2005 13:23:21 -0500

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:
> ------------------------------------------------------------------------
>

---

From: David R Oran <[email-masked]>
Date: Tue, 8 Feb 2005 14:24:43 -0500

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. Any voicemail server that can interpret  
request history can figure out what the right response to an incoming  
invite is without this.

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 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 contact used in the 2nd fork happens to be another AoR,  
> is that retargetting?
>
> And do any of these answers change if in some cases proxying is  
> replaced with a 3xx response?
>
> 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.
>
>>  > > Sipping mailing list   
>> https://www1.ietf.org/mailman/listinfo/sipping
>>  > Sipping mailing list   
>> https://www1.ietf.org/mailman/listinfo/sipping
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Mike Hammer" <[email-masked]>
Date: Tue, 8 Feb 2005 14:29:17 -0500

Paul,

To confuse things further...

Does it make a difference whether the device doing the
redirection/retargeting is in the service of the calling party, an
intermediate, or on behalf of the called party?

Mike 

   >Sent: Tuesday, February 08, 2005 1:23 PM
   >To: Francois Audet
   >Cc: 'Jesske, R'; [email-masked]'; 'Joanne McMillen'; 
   >'Elwell,John'
   >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 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.
   >
   >> 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.
   >> 
   >> 
   >> 
   >>  > [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
   >>  > >
   >>  > > 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  > >  >  > 
   >>  > This list is for NEW development of the application of 
   >SIP  > Use 
   >> [email-masked] for new developments of core SIP  >  >
   >> 
   >> 
   >> 
   >------------------------------------------------------------
   >----------
   >> --
   >> 
   >Use [email-masked] for questions on 
   >current sip Use [email-masked] for new developments of core SIP
   >