Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>
>> But I do think one ought to attempt to honor the intent of the provider
>> of the URI. IMO 3263 is pretty clear about how a sip uri is to be routed.
>
> Yes, but I'm not clear which part of 3263 *isn't* being honored. You set
> your req-uri to sip:[EMAIL PROTECTED], it reaches example.com, example.com
> says "hmm, not one of my users, I'll consider this a telephone number, and
> try the SIP-trunk or PSTN or whatever". It reached the intended sip target
> domain (example.com).
I have absolutely *no* problem with that, *if* it reaches example.com
before being translated. That is policy business between you and your
home proxy.
I have a problem when it passes through foo.com which then decides this
is a phone number and routes it to a GW without it ever going to
example.com. And I am hearing you (I think) and others saying that is
common practice and in fact necessary in many cases for calls not to fail.
>> [snipped stuff]
>> I'm not getting your point. Return routing will be based on a different
>> URI provided by the other party. All this discussion applies to that as
>> well. Whether reverse routing is possible is irrelevant here.
>
> Dean had said we would need to get "phones" to NOT use "user=phone",
> while GW's do - both using a sip: From.
That is a somewhat interesting proposal. But it does change the existing
semantics of user=phone. So I hope we can keep that as a separate
discussion.
> I had thought you were saying
> a sip scheme demands a SIP path be used.
I believe it does, just as much as sips demands that a sips path be
used, http demands that an http path be used, etc.
If somebody gives you an http URL, do you think it is an intended usage
for you to transform it into an ftp URL?
It in fact may work to transform the http into an ftp URL. But if so
that is a special case that can only be known to work based on extra
context.
In the case of sip, we might say that user=phone is provides that extra
context. IMO that is still just a heuristic, not a standard behavior. If
we want it to be a sanctioned standard behavior then we need to write
some new specs.
> So my point was that just
> because I can get a SIP request to sip:[EMAIL PROTECTED], with a signed
> From of sip:[EMAIL PROTECTED], and you store that in your address
> book, does not mean you can then 2 days later get a request to
> sip:[EMAIL PROTECTED] to stay SIP to me.
Well, there are no *guarantees*.
But IMO you ought not to be using that as your From address if you
*expect* callbacks to work and you don't at least *expect* that the
returns will work via an all-sip path. If you don't think so, then IMO
you ought to put a TEL URI in the From.
> It does not mean I wanted
> to only be reachable by SIP, and it does not mean *you* (the human) only
> want to reach me via SIP when you send it. That's all - just reiterating
> the same as before really. Nothing to see here, move along... :)
I disagree. IMO this is indeed the true distinction between sip and tel.
Paul
> -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
>
_______________________________________________
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
