[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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