Subject: RE: [Sipping] Telling a proxy which service to execute

From: "Elwell, John" <[email-masked]>
Date: Thu, 03 Nov 2005 07:45:44 +0000

Paul, 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 03 November 2005 03:58
> To: Elwell, John
> Cc: Francois Audet; Gonzalo Camarillo; sipping
> Subject: Re: [Sipping] Telling a proxy which service to execute
> 
> 
> 
> Elwell, John wrote:
> >>-----Original Message-----
> >>From: Francois Audet [mailto:[email-masked]] 
> >>Sent: 02 November 2005 20:12
> >>To: Gonzalo Camarillo; sipping
> >>Cc: Elwell, John
> >>Subject: RE: [Sipping] Telling a proxy which service to execute
> >>
> >>
> >>>It has been proposed (in 
> >>>draft-elwell-sipping-service-retargeting-00.txt) to use URI 
> >>>parameters 
> >>>for that. This approach has been compared by some in the 
> >>
> >>list to the 
> >>
> >>>approach followed by netann (draft-burger-sipping-netann-11.txt).
> >>>
> >>>It is worthwhile noting that using URI parameters to 
> convey service 
> >>>information (on any type of information) has an important 
> >>
> >>problem. If 
> >>
> >>>the request traverses a proxy that does not understand the URI 
> >>>parameter, the URI parameter may be removed. That is the 
> >>>reason why we 
> >>>moved away from URI parameters to implement URI-list 
> >>
> >>services (a.k.a. 
> >>
> >>>exploders).
> >>
> >>If a proxy arbitrarily removes parameters, it will cause lots of
> >>problems
> >>(including with Netann).
> >>
> >>However, if the proxy retargets for whatever reason, I 
> agree with you
> >>that
> >>the expectation would be for the parameters to be lost. 
> >>
> > 
> > [JRE] But that is where history-info comes in, because if the URI is
> > recorded in history-info then it is not completely lost. 
> 
> At this point I think we have come full circle.
> 
> It has been said that H-I, without service-retargetting can 
> satisfy the 
> needs of servers that are willing/able to figure out what 
> they should do 
> based on what has happened. The service-retargetting approach 
> has been 
> described as a variant of netann - a way to explicitly tell a server 
> what you want it to do rather than have it guess based on history.
> 
> Now you want to say that problems with service-retargetting can be 
> solved by using H-I. But if that is acceptable, then just using H-I 
> without service-retargetting should also be acceptable.
[JRE] No. H-I will hold the service-retargeting information in addition to
what it normally holds, so the combination of the two works, but each on its
own has some shortcomings.

John

> 
> Personally I think netann by itself (without service-retargetting) is 
> fine for those cases when, as it assumes, you *know* the uri 
> identifies 
> the target and won't need translation.
> 
> When designing a new, fully sip based, system I think it can be 
> structured in such a way that netann is sufficient. (But of 
> course some 
> may not *want* to structure their system that way.)
> 
> It does seem that there are lots of legacy systems that are 
> structured 
> on the assumption that services will figure out what they should do 
> based on information about what has happened. I don't suppose we can 
> totally ignore them. However that seems to be what H-I is 
> intended for.
> 
> Given that we have both of these mechanisms already defined, 
> why do we 
> need more?
> 
> 	Paul
> 

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Thu, 03 Nov 2005 11:43:38 +0000

Gonzalo,

Possibly. The important things in my mind for solving the "what happened"
problem are:

1. To distinguish significant retargets (which I call service retargets)
from all the other stuff that history-info gathers and that might therefore
present a confusing picture to the consumer (UAS or UAC).

2. To give consistent reasons independently of whether retargeting was the
result of redirection or not (e.g., don't give 302 sometimes and 486 other
times when the real reason is busy).

3. To give service-meaningful reasons (hence the proposal for a new
namespace rather than using SIP response codes).

4. If possible, to have a solution that has minimal impact on entities not
involved, e.g., not requiring additional actions at a UAC.

John

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 03 November 2005 09:39
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] RE: Telling a proxy which service to execute
> 
> Hi John,
> 
> I read the retargetting draft, the the information you encode as URI 
> parameters is the 'old-target' and the 'retargeting-reason'. This is 
> exactly what H-I carries.
> 
> In my opinion, the distintion between service retargeting and regular 
> retargeting is not clear and depends on what we call a service.
> 
> Therefore, it seems that the service retargeting draft attempts to do 
> exactly what H-I does, but in a way that can work thru UACs 
> that do not 
> understand H-I (is there any other extra requirement besides 
> this?). The 
> problem is that H-I was designed to take care of things like privacy, 
> security, etc, that the service retargeting draft does not tackle.
> 
> It seems that what you need is a "fixed" revision of H-I that meets 
> those extra requirements.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
> Elwell, John wrote:
> > Gonzalo,
> > 
> > In the case where the domain matches it is true that the 
> proxy MAY recurse,
> > but in other cases it is left to the UAC to recurse.
> > 
> > John
> >  
> > 
> > 
> >>From: Gonzalo Camarillo [mailto:[email-masked]] 
> >>Sent: 03 November 2005 09:14
> >>To: Elwell, John
> >>Cc: sipping
> >>Subject: Re: Telling a proxy which service to execute
> >>
> >>Hi John,
> >>
> >>the proxy recursing on the 302 will be the one adding that 
> >>information. 
> >>The 302 does not need to go all the way to the UAC.
> >>
> >>Gonzalo
> >>
> >>Elwell, John wrote:
> >>
> >>>Gonzalo,
> >>>
> >>>No I'm not saying I don't want H-I at all. I was trying to 
> >>
> >>avoid needing
> >>
> >>>special support at a UAC. With your proposal it requires 
> >>
> >>the UAC to take
> >>
> >>>special action to copy H-I from the 3xx to the retargeted 
> >>
> >>Request-URI -
> >>
> >>>otherwise the information is lost.
> >>>
> >>>John
> >>> 
> >>>
> >>>
> >>>
> >>>>From: Gonzalo Camarillo [mailto:[email-masked]] 
> >>>>Sent: 03 November 2005 09:01
> >>>>To: Elwell, John
> >>>>Cc: sipping
> >>>>Subject: Re: Telling a proxy which service to execute
> >>>>
> >>>>John,
> >>>>
> >>>>in a previous email you are saying that service retargetting 
> >>>>needs H-I 
> >>>>in order to work (in case a proxy in the middle changes the 
> >>>>Request-URI), and now you are saying that you do not want to 
> >>>>use H-I at 
> >>>>all and only use service retargetting... I am confused.
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Gonzalo
> >>>>
> >>>>
> >>>>Elwell, John wrote:
> >>>>
> >>>>
> >>>>>Gonzalo,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>From: Gonzalo Camarillo [mailto:[email-masked]] 
> >>>>>>Sent: 02 November 2005 17:42
> >>>>>>To: sipping
> >>>>>>Cc: Elwell, John
> >>>>>>Subject: Telling a proxy which service to execute
> >>>>>>
> >>>>>>Folks,
> >>>>>>
> >>>>>>it seems to me that the History-Info approach can meet the 
> >>>>>>requirements 
> >>>>>>coming from services that need to know what has happened to 
> >>>>>>this request 
> >>>>>>so far.
> >>>>>
> >>>>>[JRE] With the significant disadvantage that the UAC has to 
> >>>>
> >>>>support the
> >>>>
> >>>>
> >>>>>generation of History-Info for this to work. It is my 
> >>>>
> >>>>opinion that proxies
> >>>>
> >>>>
> >>>>>and B2BUAs will support the addition of History-Info 
> >>>>
> >>>>entries, but support by
> >>>>
> >>>>
> >>>>>UAs might be limited to reading what is received rather 
> >>>>
> >>>>than adding entries.
> >>>>
> >>>>
> >>>>>The service-retargeting solution is the only solution 
> >>>>
> >>>>proposed that does not
> >>>>
> >>>>
> >>>>>require special UAC support.
> >>>>>
> >>>>>John
> >>>>
> > 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Nov 2005 14:01:29 -0600

No it's not the case where retargeting is in PSTN.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Thursday, November 03, 2005 01:39
> To: Elwell, John
> Cc: sipping
> > In the case where the domain matches it is true that the proxy MAY 
> > recurse, but in other cases it is left to the UAC to recurse.
> > 
> > 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
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
>