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

["Francois Audet" <[e-mail]>]

> 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