RE: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: Dean Willis [mailto:[e-mail]]
> Sent: Thursday, January 17, 2008 2:13 PM
> To: IETF SIP List
> Subject: [Sip] Vocabulary and problem statement for Request-URI,
> retargeting, and SIP routing (long, but read it!)
>
> So to recap, we have three basic proxy operations in RFC 3261:
>
> 1) Request routing, which preserves the request URI.
>
> 2) Request rerouting, which changes the request URI but preserves the
> identity of the request's target.
>
> 3) Request retargeting, which changes the request URI and changes the
> identity of the request's target.
>
> We also have a related operation:
>
> 4) Request redirection, which informs an upstream node about a new
> identity to target instead of the original.

This is described from the aspect of the downstream node sending the 3xx, right?  Vs. what it is for the upstream node recursing on the 3xx? (which has no idea if it's performing (2) or (3) when this occurs, but I guess could be added to the 3xx contact as a param such as described in JR's draft)

So if a proxy is doing "redirection" it is sending a 3xx, whereas the upstream proxy or UAC getting that 3xx is not doing redirection, but in fact "recursing".


> Conclusion:
>
> New proposed vocabulary for proxy operations: request routing,
> rerouting, retargeting, and redirection.

Sure.  Except I'm with Joel in that I don't know how a system knows when it's doing rerouting vs. retargeting in all cases, even if we stick to the 4474-type litmus test.  And unfortunately a lot of systems in the path have user-configured rules for what they do with the req-uri.

-hadriel



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