> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Kyzivat > > Now Hadriel has made a case that it is the SBC's job to fix this up.
Hmm... I don't seem to recall saying that at all! Something has to do it, but it by no means has to be an SBC. It could, for example, be the same proxy that decided it could not resolve it locally and to pass the 302 upstream. > So > when the URL exits the domain in which it will work, then the SBC should > fix it up with the domain it is going into. I guess that could make > sense if that SBC was acting as an agent of *both* domains. But > typically it is only acting as an agent of one domain. An SBC acting for > b.com has no business changing the domain of the URL to a.com, since > doing so is (or isn't) a policy of a.com. On the contrary, one could argue a.com has no business changing b.com's domain to a.com, but I see nothing wrong with b.com changing the domain to a.com. Don't get me wrong - the whole thing sucks, but from a "who's business is it" perspective I think it's b.com's. Otherwise you're essentially arguing that b.com cannot retarget requests to a.com either. What's "wrong" is for a.com to retarget requests addressed to b.com to itself instead. > A way around that is to say that if the URI contains b.com, then an SBC > acting for b.com, when it knows it won't honor that, can change it to a > TEL URI when it exits the domain. It then may well go through another > SBC acting for a.com as it enters the a.com domain. That SBC could > change the TEL URI to an a.com URI if that will be handled correctly > within the a.com domain. Funny enough I've seen a case where that exactly happens. It seemed crazy to me though. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
