[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comparison of retargeting proposals
> -----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.
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)
> And I don't see in here the place where the Request-URI is changed to the
> Contact
> that was used in the REGISTER (i.e., where example.com changes
> bob at example.com to
> bob at bobpc.example.com). That is really the missing part, no?
That is R2 in the diagram.
> Is that what you call RRT? And if so, why is there an extra leg between it
> and the
> UAS? Is it because P4 is an outbound proxy?
P4 is an outbound proxy. But to be clear, what's going on here is call goes to bob at biloxi.com at R1, gets re-targeted by R1 to charlie at cambridge.com at R2, and R2 resolves it to charlie at trs80.cambridge.com (assuming Charlie's UA is trs80).
> And I still don't see why C != E. It would only be different if loose
> route was not
> used by the proxies (e.g., RFC 2543 proxies). Is that what you mean? If
> so, doesn't this
> mean P-Called-Party-ID is essentially useless and IMS can't use it
> anyways? So we should
> just fix P-Called-Party-ID spec instead?
I don't know that part. I am not taking any "side" on this issue. I am merely trying to bring clarity through ascii art. :)
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.
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com]
> >
> > > -----Original Message-----
> > > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> > Behalf Of
> > > Francois Audet
> > >
> > > Can you give one. It seems to me that in both cases, the
> > headers will
> > > include the last Request-URI "just before it's replaced by
> > the Contact
> > > used in Registration".
> >
> > From a previous email I sent a long time ago, given the
> > following reasonably complex scenario, where "RTRG" means
> > Re-Targeting, "RRT" means Re-Routing, "RT" means Routing, and
> > the single letters represent connections:
> >
> > RTRG RRT
> > +---+ +---+
> > |R1 | |R2 |
> > B /+---+\ C E /+---+\ F
> > RT / \ RT RT / \ RT
> > +---+/ \+---+ D +---+/ \+---+
> > |P1 | |P2 +---+P3 | |P4 |
> > A /+---+ +---+ +---+ +---+\ G
> > / \
> > +---+/ \+---+
> > |UAC| |UAS|
> > +---+ +---+
> >
> > Goal: to get the req-uri seen on "C" (right?).
> >
> > UA-Loose-routing sets the req-uri to that seen on connection "C".
> > Target gives you C.
> > PCPID gives you E.
> > Hist-Info gives you A,B,C,D,E,F.
> > To header gives you A.
> >
> > C != E, because P2 and P3 could be swapping req-uri's as they
> > 3261 route. UALR draft says "stop swapping when you route",
> > but Target draft does not.
> >
> > -hadriel
> >
> >
_______________________________________________
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