On 7/14/14 7:47 PM, James Cloos wrote:
"PK" == Paul Kyzivat <pkyzi...@alum.mit.edu> writes:

PK> If you give out only URIs with domain names, then that is what
PK> clients should be using.

PK> Only servers that are "responsible for the domain" are permitted to
PK> translate those URIs.

Thanks.  That is what I expected when I wrote the validation code, but I
do not have access to enough different client software to be certain.

PK> Common practice has developed that servers are free to manipulate any
PK> URI that appears to include a phone number, replacing the domain name
PK> as they see fit.

PK> IMO this is *wrong*, but I haven't been able to convince anybody else
PK> of that.

So, if someone were to dial tel:+878107472467264, and their client did
the NAPTR on e164.arpa and found sip:7472467...@jhcloos.com, either
followed that by an NAPTR on jhcloos.com or directly looked for a sip
SRV there, then even though the invite to the proxy SHOULD be to
7472467...@jhcloos.com it might end up being to 7472467264@PROXY_NAME
or to 7472467264@PROXY_IP?  But sip:cl...@jhcloos.com always will
have that string in the invite?

AFAIK that scenario is entirely hypothetical, because public enum has been a failure. Carriers use enum, but they do so with private enum DBs and peering relationships that determine how they interface with one another.

That world is ruled by SBCs. For the most part they keep remapping numbers, changing the domain name as the request moves from peer to peer.

But if you were in such a situation, then you probably would know the rules they play by and wouldn't be surprised.

        Thanks,
        Paul

        Thanks,
        Paul

        Thanks,
        Paul

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to