OK. I think I understand.

Since the SIP request is injected straight into SER via the t_uac_dlg() FIFO command, I had presumed the request would get dumped into the route[0] block like any other request coming into SER from a UDP port. If this were the case I'd expect the normal "if(uri == myself)" type checks to catch the request and do the appropriate thing. But if I follow your reply, this isn't the case.

If I understand what you say correctly, the t_uac_dlg() command works just like some UAC out on the network, and needs to have the IP address of its proxy either hard coded, or resolvable via some means (hosts file, DNS). Once this resolved, it sends the request to SER via networking calls and normal processing ensues. Is this correct ?

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" form instead of "sip:name@ip" form. Is this all correct ?

Presuming the above is correct, one problem I can see with this requirement is that in some instances, it may be impossible for someone to add the DNS SRV entries (no access to DNS server, for instance), and impractical to add /etc/hosts aliases for the SIP domain, since doing so could possibly break other things in the system, such as email routing on that host (I think sendmail, etc would assume that the machine was the mail server for that domain if such an alias existed). In this sort of situation, the user might want to hard code the IP address of the SIP proxy to contact, much as you do when you configure SIP phones.

If you wanted to somehow "hard code" the SIP proxy called by changing the PHP code in SERweb, could you do so "properly" ? I could see how changing the URI from "sip:user@domain" to "sip:user@ip-of-SIP-proxy" in the PHP would work, but wouldn't that break a multi-domain situation, since the domain of the user in question would be lost ? Perhaps if just the INVITE URI were changed to "sip:user@ip-of-SIP-proxy" form, and the "To: " header in the SIP request were left in "sip:user@domain" form, things would still work ? Or perhaps other headers could be changed/added in the SIP request that would allow t_uac_dlg() to figure out which IP to contact for the request without needing to do a host lookup ? Or maybe the best approach would be to add an optional IP-address argument to the t_uac_dlg() command which specifies the SIP server to call (for instance, ":t_dlg_uac:reply_fifo_name[:IP of SIP server to call]") ?

TIA, Jim

Jiri Kuthan wrote:

Jim,

CTD acts as a SIP client -- i.e., it takes mydomain.com and tries to resolve it via DNS. If the resolution fails, the transaction fails. That's completely orthogonal to function of "alias" which is used for proxy server's domain matching.

if mydomain.com is served by the same server, CTD initiates a transaction, sends it to itself, and in proxy mode it recognizes it as a request for itself using alias.

-jiri

At 04:46 PM 10/30/2003, Jim Burwell wrote:

...

Hi,

I was trying to get click-to-dial working from SERweb and it was failing for unclear reasons. I then experimented with the "ctd.sh" script, which does the same thing as the SERweb PHP code. I found that it would fail during the 'dummy invite' stage, returning an odd error if I used a URI which used a SIP domain/realm, but would work fine if I used the IP address of the SIP proxy as the domain. i.e.:

./ctd.sh sip:joebob@mydomain.com sip:billybob@mydomain.com <- fails ./ctd.sh sip:joebob@1.2.3.4 sip:billybob@mydomain.com <- succeeds

The reply from SER would be "500 fifo_uac: no mem for hf block" . The log file would have these errors:

ERROR: mk_proxy: could not resolve hostname: "mydomain.com" ERROR: uri2proxy: bad host name in URI sip:joebob@mydomain.com ERROR: uri2sock: Can't create a dst proxy ERROR: get_hf_block: send_sock failed ERROR: fifo_uac: no mem for hf block

So it appears that SER didn't understand that the URI's domain was itself, even though there's a host alias line in the ser.cfg file listing "mydomain.com" as an alias for this host. It's as if it thinks it needed to relay the transaction to another SIP router, and look up an IP to do so. If "mydomain.com" were placed in /etc/hosts as an alias for the system SER was running on, or if a DNS SRV entry for the SIP domain were created pointing to the SER system, voila, the "sip:user@domain" form would work just fine.

Is this a bug ? I think SER isn't checking SER host aliases against the SIP domain if the SIP request comes in via the fifo t_uac_dlg() command.

I'm using the SER release 0.8.11-r1, aka the "stable CVS" release.

TIA, Jim

-- +---------------------------------------------------------------------------+ | Jim Burwell - Sr. Systems/Network/Security Engineer, JSBC | +---------------------------------------------------------------------------+ | "I never let my schooling get in the way of my education." - Mark Twain | | "UNIX was never designed to keep people from doing stupid things, because | | that policy would also keep them from doing clever things." - Doug Gwyn | | "Cool is only three letters away from Fool" - Mike Muir, Suicyco | | "..Government in its best state is but a necessary evil; in its worst | | state an intolerable one.." - Thomas Paine, "Common Sense" (1776) | +---------------------------------------------------------------------------+ | Email: jimb@jsbc.cc ICQ UIN: 1695089 | +---------------------------------------------------------------------------+ | Reply problems ? Turn off the "sign" function in email prog. Blame MS. | +---------------------------------------------------------------------------+

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

Comments inline...(the way they're supposed to be before windows mail clients messed it all up :-).

Jiri Kuthan wrote:

At 12:43 AM 10/31/2003, Jim Burwell wrote:

...

OK. I think I understand.

Since the SIP request is injected straight into SER via the t_uac_dlg() FIFO command, I had presumed the request would get dumped into the route[0] block like any other request coming into SER from a UDP port. If this were the case I'd expect the normal "if(uri == myself)" type checks to catch the request and do the appropriate thing. But if I follow your reply, this isn't the case.

If I understand what you say correctly, the t_uac_dlg() command works just like some UAC out on the network, and needs to have the IP address of its proxy either hard coded, or resolvable via some means (hosts file, DNS). Once this resolved, it sends the request to SER via networking calls and normal processing ensues. Is this correct ?

A UAC does not need to use any proxy. If request uri contains sip:joe@foo.bar, foo.bar gets resolved via DNS and SER sends there. If r-uri contains IP address, the request gets sent there. If the domain name refers to the same host, the request will loop through your server.

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).

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@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.

Granted, but I was talking about getting CTD as implemented in SERweb work correctly. 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.

...

Presuming the above is correct, one problem I can see with this requirement is that in some instances, it may be impossible for someone to add the DNS SRV entries (no access to DNS server, for instance), and impractical to add /etc/hosts aliases for the SIP domain, since doing so could possibly break other things in the system, such as email routing on that host (I think sendmail, etc would assume that the machine was the mail server for that domain if such an alias existed). In this sort of situation, the user might want to hard code the IP address of the SIP proxy to contact, much as you do when you configure SIP phones.

you don't need to manipulate DNS maps for c-t-d. Just send invitations to existing valid DNS domains, be it one you server or some completely other one.

Huh ? You've confused me. This seems contradictory. In order for a domain name to be 'valid' per your meaning in this context is for it to actually point to an IP. In order to point your DNS domains to an IP, you must "manipulate DNS maps", e.g., configure your DNS server to point the domain(s) in question to some IP address that can handle the SIP requests, or configure SRV records. Otherwise, CTD fails, period.

The only solutions I could come up with are:

1) point the domain to the IP of your SIP server

This would work, but if you are using your organizations domain as your SIP domain, and the domain is already pointed to the IP of something other than the SIP router (typically, a company domain is pointed to a web server so that both www.foo.bar and foo.bar both take you to the web server), it wouldn't work.

2) hack the PHP code to translate known domain(s) into the IP addresses of their respective SIP servers

This would also work, but I fear in a situation where one SIP server is serving multiple domains, translating sip:user@foo.bar -> sip:user@1.2.3.4:xzy might break things, since I'm not sure if the SIP router looks at additional headers to determine the destination domain, or just the INVITE.

It's also somewhat irksome, since this is a job a SIP router is supposed to do, not your CTD dispatcher code.

3) use DNS SRV resource records for your domain(s)

This seems to be the cleanest way to do it, and is fortunately supported by SER.

4) have some way for the SER UAC in the t_uac_dlg() call to specify a "next hop" to send the message to for processing, instead of trying to process it itself, much like SIP phones' "proxy server" settings.

Either by supplying an IP/hostname:port in the command, or, if possible, via the SIP message itself (I'm not enough an expert on the SIP protocol to know if this is possible).

Hopefully I'm not completely missing something here.

-jiri

- Jim