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

From: "Elwell, John" <[email-masked]>
Date: Thu, 03 Nov 2005 09:17:40 +0000

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

> -----Original Message-----
> 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
> >  
> > 
> > 
> >>-----Original Message-----
> >>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,
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>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
> >>
> 

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 03 Nov 2005 11:39:22 +0200

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

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