[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comparison of retargeting proposals
Well, this just proves that it ain't that clear. Looks like Dean's
definition of "re-routing" is broader than Hadriel's since it includes
strict routing in "the middle" not just "the end". Whatever we do, we should
get clear terms for "re-routing".
Jonathan's draft had the merit to make all this clearer.
Anyways, thanks Hadriel for confirming my understanding of your diagram.
I still don't see the difference between P-Called-ID and Target, i.e.,
"what are the cases where C != E", unless there is 2543-style strict routing.
And if there is, then I fail to see how P-Called-ID would be used: seems to
me if P-Called-ID points to C instead of E, it is broken and should be fixed.
Of course maybe it's my non-existent knowledge of IMS. My question to Christer
would be "Is P-Called-ID as defined today, pointing to C, broken???".
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Wednesday, April 02, 2008 18:46
> To: Hadriel Kaplan
> Cc: Audet, Francois (SC100:3055); Christer Holmberg; Hans
> Erik van Elburg; Juha Heinanen; sip at ietf.org; DOLLY, MARTIN C, ATTLABS
> Subject: Re: [Sip] Comparison of retargeting proposals
>
>
> On Apr 2, 2008, at 6:05 PM, Hadriel Kaplan wrote:
> >
> >
> >> -----Original Message-----
> >> From: Francois Audet [mailto:audet at nortel.com]
> >>
> >> Re-Targeting (RTRG) is when a Proxy changes a Request-URI to a
> >> different one, outside of normal routing. That's ok. For example,
> >> bob at example.com to alice at example.com.
> >> What is the difference between RRT (Re-Routing) and Routing
> >> (Routing)? I don't get it.
> >
> > I believe, based on the email discussion back in January, that "Re-
> > Targeting" is when a Proxy re-targets the request to a new
> entity, so
> > yes for example from bob to charlie. In that situation, I believe
> > what both Jonathan and Christer want is the "target- info"
> (the stuff
> > we're trying to preserve) to be replaced by the new set (charlie's
> > set).
> >
> > Re-Routing is when the proxy/registrar replaces the req-uri due to
> > AoR->contact resolution. In that case we want to preserve the pre-
> > resolved target info.
> >
>
> The difference between retargeting and rerouting is that
> rerouting preserves the expected response identity, and
> retargeting doesn't.
>
> Assume connected-identity. In a "direct" call, one where no
> proxy routing is done, we'd expect to see that the identity
> sent by the target corresponds to the identity given for the
> target in the request URI.
>
> That is, if Alice has invited Bob, she's expecting the
> connected- identity to be sourced from Bob.
>
> This is preserved by typical "proxy contact routing", to
> which I applied the term "rerouting". The request URI gets
> changed by the proxy, but the targeted identity doesn't.
>
> So if Alice sends an INVITE for Bob's AOR to Bob's proxy, and
> Bob's proxy reroutes the INVITE to Bob's UA using a
> registered Contact, Bob still gets the call, and a
> connected-identity expressed by his UA will still be for "Bob".
>
> However, if Bob's proxy retargeted the request to
> SpanishInquisition, the connected identity would no longer
> match with the request. I call this the "unanticipated
> respondent problem". After all, nobody expects the Spanish
> Inquisition to answer Bob's calls.
>
> This could be a real problem is we were using security
> functions, since Alice might 1) not have keys for use with
> the Spanish Inquisition, and 2) Alice might reasonably wonder
> why they answered Bob's call.
>
> Had we instead used a 302 to redirect Alice to the Spanish
> Inquisition, she'd at least be forewarned.
>
> So, routing and rerouting operations imply that the response
> identity is equivalent to the pre-operation target identity.
> Retargeting implies that the response identity is not
> equivalent to the pre- operation target identity.
>
>
> > Routing is when a proxy routes. I believe the intention
> was that this
> > mean the proxy does not touch the req-uri, but my guess is
> that's not
> > agreed is reality. (more on that later)
>
> In RFC 2543, routing always required changing the ReqURI.
> RFC 3261 loose-routing changed this, and proxies only change
> the Request URI when changing the target. RFC 3261 does not
> distinguish between target changes that change the identity
> of the target and those that do not, hence the new terms
> "rerouting" and "retargeting".
>
> much text deleted . . .
>
> >
> > My personal experience is proxies replace req-uri during routing a
> > LOT, even when they're not resolving AoR->contact nor "re-
> targeting".
> > And what they're changing the req-uri to does not usually
> affect the
> > identity of the called party, because the username portion is not
> > being changed, and it's an e.164. So PCPID "works". But for this
> > target-info use-case you want parameters from the original req-uri,
> > and those may not be there by the time it gets to R2 and a PCPID is
> > created. So that's my guess of why C != E. But it's just a guess.
>
> I'd call that operation rerouting, not routing. It is the
> functional equivalent of replacing the request-URI with a
> Contact -- it's just that the new request-URI is determined
> by some means other than registration against the AOR. This
> might be, for example, via static provisioning, or by
> matching against a TRIP routing table. The fact that the
> userparts encode phone numbers is essentially irrelevant to
> the question of what type of operation (routing, rerouting,
> retargeting) is used, although it might be very important to
> how the proxy might decide which operation to use and which
> destination to encode.
>
> --
> Dean
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip