31 Oct
2003
31 Oct
'03
10:09 a.m.
At 07:58 AM 10/31/2003, Jim Burwell wrote:
[..]
Yes. I understand. But the UAC in t_uac_dlg() appears
not to be able to use a proxy, unless the domain given is pointing to the proxy itself, or
an IP address of the proxy is given. The UACs in SIP phones and such can be set up to
point to a proxy, and use it, obviating the need for a valid DNS domain. It's common
in most enterprises to use the DNS domain name of the organization as an email address and
a SIP domain, but fairly uncommon to have anything associated with the domain on the DNS
server except MX records and CNAMEs or As pointing to say, a web server (typical). Most
enterprises would not point the company domain to a SIP server. I guess this is what the
SRV record is for. Or, alternatively, I guess you could put your SIP universe in a
subdomain(s).
yes, that's what DNS SRV is good for. use it, its a good thing.
I think part of my misunderstanding here was that I was
looking at a SIP domain or realm as something different than a DNS domain. More of an
administrative/organizational scope than just a DNS domain name.
Granted, but I was talking about getting CTD as implemented in SERweb work correctly.
it already is -- it initiates CTD to target the user indicate. If the target is
not resolvable, it fails which is a feature. It is user's responsibility to
put valid entries in his or her phonebook. (be it IP, DNS/SRV, DNS/A)
If this is
all true, then it means that for the current SERweb CTD functionality to work, you need a
host file or DNS entry for all SIP domains served by your SER server, since SERweb
delivers the dummy INVITE URI in the <sip:name@domain>"sip:name@domain"
form instead of <sip:name@ip>"sip:name@ip" form. Is this all correct ?
the UAC does not care if the domain is served by SER or not. It just sends to
the address in request-uri. If it includes an invalid DNS name, the request will
fail. In this case, the items you click on return sip
addresses with domain names and not IP addresses. And in this case, the UAC requires that
the domain name point to something with an IP address to do anything but reject it. Of
course, the only sort of IP address that makes sense to point at is some sort of SIP
server which knows how to route the request. If the DNS IP is already pointed at say,
your web server, as is typical in most enterprises, you're out of luck, unless you can
tell it to ignore the IP resolved by the domain and just 'go to this proxy'
instead. Of course, this is another case where the SRV type resource works well, since it
allows overloading a domain name with different per service destination IPs. I tested it
with SER, and the presence of a SIP SRV record overrides where domain name is pointing IP
wise. My domain was pointed at my web server, and my _sip._udp SRV record was pointing to
my SIP proxy, and the SER UAC preferred the SRV over the resolved IP, thankfully.
yes, that's the defaul behaviour. try SRV first.
-jiri