Hadriel Kaplan wrote:
>
>> -----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.
OK, *something* has to do it.
In *some* cases a proxy could do it. But in many cases only a UA is
allowed to do it. For instance changing the From URI. If we are arguing
that some middlebox is supposed to make this problem go away generally,
then it will have to be a middlebox that is a UA, hence a B2BUA. Ones
that perform that sort of role are generally called SBCs.
>> 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.
Maybe I need to state my point better.
Depending on the type of box and the header that is being modified, a
box acting for b.com may indeed be permitted to replace a b.com URL with
some other URL, even an a.com URL. (In fact it doesn't matter what the
domains of the two urls are, it may be able to do it.)
What is a problem is for b.com to *fabricate* an a.com URL to insert.
b.com in in general not privy to the policies governing the construction
of urls in the a.com domain, and so has no business constructing one.
And that is what is happening if b.com "changes the domain to a.com" in
the URL.
>> 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.
Its not at all crazy.
What it means is that b.com is converting one of its own URLs, whose
semantics it understands, into a url with standardized semantics. Then
a.com is converting a url with standardized semantics into a url in the
a.com domain, whose semantics *it* understands.
The alternative is to declare any sip URI with user=phone has
standardized semantics, and that all domains must support that form. Or,
every box making the conversion must understand the policies of both sides.
It seems that most are now agreeing that tel URIs would be the right way
to exchange phone numbers, but are concerned with backward compatibility
to all those devices that purportedly don't support them. The migration
is eased of we assume that SBCs (which seem to be everywhere anyway) can
do the fixup for those that don't support it. And over time the fixups
could be eliminated.
Paul
_______________________________________________
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
