[Serusers] t_uac_dlg() bug ?

Jiri Kuthan jiri at iptel.org
Fri Oct 31 10:09:31 CET 2003


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.
>
>
>>>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 at domain>"sip:name at domain" form instead of <sip:name at ip>"sip:name at 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.
>
>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)

>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 




More information about the sr-users mailing list