RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

["Michael Hammer \(mhammer\)" <[e-mail]>]

With respect to 302 v. 486, there seems to be differences of opinion
about which takes precedence.  You say 302, others say 486.  This begs
for a BCP.  Seems like the supplied Reason header should take
precedence. 

Correction, I should have said first non-3xx entry to get the voicemail
behavior you describe.

Below, I am not talking about modifying the H-I headers information at
all, just making use of what is present in that header, which doesn't
seem to be defined.

And as for what an SBC will muck with or not, anything in the message is
open to manipulation.  I don't know of anything that could stop it from
stripping parameters it doesn't know about.

Mike


> -----Original Message-----
> From: Francois Audet [mailto:[e-mail]] 
> Sent: Friday, October 14, 2005 7:21 PM
> To: Michael Hammer (mhammer); sipping
> Cc: Elwell, John
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> > I think it is possible to receive a 302 with Reason header 
> saying 486. 
> > Is it ambiguous as to whether 302, 486, or both should be 
> indicated in 
> > the H-I header?
> 
> Think of a gateway having "call forwarding busy" enabled for 
> a particular phone behind that gateway.
> 
> If you make a request to it, it will send a 302 with the Call 
> Forwarded-to address.
> 
> The "Busy" reason is lost.
> 
> The "forwarding" may be done by a proxy/redirect server, or 
> by the endpoint. 
> That is part of the issue. This distinction is immaterial 
> from a "service retargeting" point of view, but for 
> History-Info, it is very different (i.e.
> for SIP it is important, but not for the desired service).
> 
> With the service retarget draft, the idea is that whoever 
> does the retarget (proxy, gateway, end device) does the work 
> of adding the proper URI. It doesn't matter to anybody else 
> (in particular proxies in the middle).
> I
> > Is it clear in retargeting which would be used?
> 
> Yes, as above.
> 
> > I would have thought that the VM service would be most 
> concerned with 
> > the last line of H-I only, since that would be the one that 
> would be 
> > equivalent to what is put in R-URI.  If the 302 v 486 business is 
> > settled, then perhaps it would be the last non-3xx header 
> that is of 
> > interest.
> 
> This is how we get into people "modifying" unilaterally 
> History-Info to suit their desired behavior (which scares me a lot..).
> 
> In many environment, it is actually the first redirection 
> that matters.
> If you phone me, I'm forwarded to John, and John is forwarded 
> to voicemail, then you get MY mailbox (not John's). (let's 
> not discuss the merit of
> this: 
> it just is the way it is).
> 
> A retargeting entity would do whatever it wants with the 
> retargeted URI, which is fine.
> 
> If only History-Info is usable, you have to "muck around" 
> with History-Info.
> This is really, really bad...
> 
> > Hopefully, no SBC will muck with either R-URI params or the H-I 
> > header.
> 
> Even an SBC wouldn't muck around with a request-URI...
> 
> But SBCs will almost certainly muck around with History-Info...
> 

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