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

From: "Mary Barnes" <[email-masked]>
Date: Wed, 9 Feb 2005 17:39:28 -0500

Hi all; I just got the response that this is being held for moderator
approval, so I have snipped the thread as indicated below, as I think it's
important to clarify the role  of History-Info in this discussion. 

Mary

-----Original Message-----
From: Barnes, Mary [NGC:B601:EXCH] 
Sent: Wednesday, February 09, 2005 4:27 PM
To: 'Elwell, John'; Paul Kyzivat
Cc: 'Jesske, R'; Audet, Francois [SC100:9T51:EXCH]; [email-masked]';
'Joanne McMillen'
Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01

One small point embedded below [MB]. 

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Wednesday, February 09, 2005 3:41 PM
To: Paul Kyzivat
Cc: 'Jesske, R'; Audet, Francois [SC100:9T51:EXCH]; [email-masked]';
'Joanne McMillen'
Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01

Paul,

I greatly appreciate your taking time to write such a detailed and helpful
response. My further comments in-line.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 09 February 2005 16:06
> To: Elwell, John
> Cc: Francois Audet; 'Jesske, R'; 'Joanne McMillen'; [email-masked]'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> John - a few comments inline and discussion at end.
> 
> 	Paul
> 
> Elwell, John wrote:
> > 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[email-masked]] 
> >>Sent: 08 February 2005 18:23
> >>To: Francois Audet
> >>Cc: 'Elwell, John'; 'Jesske, R'; 'Joanne McMillen'; 
> [email-masked]'
> >>Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> >>
> >>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.
> > 
> > [JRE] This is what I would regard as "normal retargeting".
> > 
> > 
> >>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?
> > 
> > [JRE] I would still regard this as "normal retargetting" - 
> the difference
> > between serial and parallel forking is just a matter of timing.
> > 
> > 
> >>Same, but the 2nd fork is to a VM server - is that retargetting?
> > 
> > [JRE] I guess it depends whether the VM server has 
> registered using the same
> > AoR or a different AoR - see below.
> 
> Why should it make a difference how the VM server has registered, as 
> long as the same behavior results if/when the VM server is reached?
[JRE] OK, I see your point.
> 
> >>Same, but the contact used in the 2nd fork happens to be 
> >>another AoR, is 
> >>that retargetting?
> > 
> > [JRE] I would consider this retargeting but not as normal 
> retargeting. From
> > the point of view of the UAS reached as a result of this, 
> this UA receives a
> > request that, according to history-info, was originally 
> targeted at an AoR
> > that is not an AoR against which it has registered. Or 
> alternatively, a
> > gateway receives a request to an AoR identifying an entity 
> in a legacy
> > network that, according to history-info, is not the entity 
> originally
> > targeted. In these cases the reason for this change of 
> target may not be
> > clear.
> 
> So you are saying that something special has happened here, 
> and it ought 
> to be reflected as such using your new Reason causes?
> 
> Who is responsible for realizing that something special has 
> happened and 
> inserting the Reason? In this case it seems like it must be 
> the proxy. 
> But how would it know to do this?
[JRE] I am beginning to see why you have an issue of how to distinguish
between normal retargeting and redirection. I still think there is a
distinction, but perhaps my earlier attempts to explain were misguided. The
point is, that if a UAC sends a request to your AoR and it gets immediately
retargeted by the proxy in your domain to one of your contact URIs and
obtains a 2xx response from that UAS, then I would not consider that to be
redirection and worthy of any additional information to accompany the
history-info. In fact, I seem to recall that earlier drafts of history-info
would not have considered that case worthy of generating a hist-info field.

[MB] History-Info would be captured (subject to local policy, etc.) for ANY
retargets. 
" The History-Info header is added to a Request when a new request is 
   created by a UAC or forwarded by a Proxy, or when the target of a 
   request is changed."
It's then up to the end application to sort through what's been collected
and figure 
out which entries are meaningful to that application.  This discussion is
not 
around whether History-Info is collected for particular scenarios, but
whether there 
isn't a need to extend the Reason header to provide more information, which
SOME 
applications might find useful.  What needs to be justified is whether the
extension 
to the Reason header is useful for ANY application or whether the
application can 
derive the information from the series of History-Info entries it receives.
Per my 
previous posting, is there a use case other than VM?  
[/MB]

However, if that request receives a negative response from that first UAS
(or no response) and as a result the request gets retargeted to a second
UAS, I would consider that to be redirection and would wish history-info in
the retargeted request to be accompanied by sufficient information to
indicate the reason for that retargeting. In this case the usefulness of
that redirection reason depends on circumstances. I can see that the second
UAS could potentially benefit, since it might help it figure out why the
request has arrived there (independent of whether it is a VM system or a
device with a human user). On the other hand, for the history-info that gets
reflected back to the UAC that last field may or may not be of use to the
UAC or its user. If the second UAS is just another contact for your AoR, it
is unlikely that that history-info field will be of much interest to the
caller, since the request has still gone to you (or a UAS representing you).
On the other hand, if the retargeting is to a different AoR, the proxy for
which retargets the request again to a registered contact URI for that AoR,
then I can see that the UAC might be interested in the reason for retarget
to that second AoR, as well as the fact that this has happened.

-----remainder of thread snipped by Mary--------------------------------
_______________________________________________
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