Hi,

A client of mine has encountered a problem with SER. When he has aliases which point to other aliases, SER fails to route a call UNLESS the SIP domain of the callee has an /etc/hosts entry associated with it (or, presumably, a DNS A record for the domain, or a DNS SRV record for SIP inside that domain).

For example:

ser.cfg has line: alias="domain.com" Callee is "alias1@domain.com" SER user alias "alias1@domain.com" -> "sip:alias2@domain.com" -> "sip:user@domain.com" SER usrloc entry exists for "user@domain.com" -> "sip:user@[IP-of-user's-phone]" /etc/hosts file has entry in the form of: 1.2.3.4 siprouter siprouter.domain.com domain.com CALL WORKS

However, change /etc/host file entry to: 1.2.3.4 siprouter siprouter.domain.com (remove alias for whole domain) CALL FAILS

Other, more simple SER user aliases WORK in BOTH scenereos: SER user alias "somealias@domain.com" -> "sip:someuser@domain.com" SER usrloc exists for "someuser@domain.com" -> "sip:someuser@[IP-of-user's-phone]" CALL WORKS This is whether the "domain.com" /etc/hosts alias exists or not.

So, SER appears to NEED to resolve an IP address for the SIP domain to do two (and above) levels of alias indirection. It's almost as if the resolution of aliases isn't recursive or something (seeing how single-level aliases work, and it doesn't try to resolve an IP to "call out" to another SIP router).

Note, that "ser.cfg" DOES have a line alias="domain.com", so SER should know that it is responsible for this SIP domain.

It appears that SER is trying to make a network call to this SIP domain before it even begins processing the ser.cfg script, where it would match the if(uri == myself) condition because of the "alias=" lines. Perhaps a heuristic needs to be put in somewhere to check the condition "callee_domain == myself" before SER goes through the trouble of trying to resolve the callee domain when it will just point back at itself ?

This problem reminds me of the one I ran into earlier with the t_uac_dlg() FIFO call used by the click-to-dial scripts. This also had the problem where SER would try to resolve its own SIP domain before checking if SIP_DOMAIN == myself.

The quick and dirty fix was to add a /etc/hosts alias (as illustrated above), but this has the unwanted effect of breaking sendmail mail routing, requiring an ugly rewriting rule hack to "fix" the problem (sendmail thinks myself == mail domain, and recipients w/ @domain.com addresses are local users).

The "good" fix is to use a DNS SRV entry (at least I hope this would fix both SER problems mentioned here).

But, should SER really be doing these name resolution calls in situations like this ? Isn't this inefficient ? It seems like a bug to me :-). It seems to me that SER should pay attention to the "alias=" lines in all phases of calee routing, with the exception of when the calee's SIP address is resolved down to userloc entry pointing it to another SIP device.

Perhaps my concept of the purpose/scope of a SIP domain is wrong ? I assume that a SIP server, or group of servers with identical configurations/databases (for load balancing) is "authoritative" for a domain, and unless an alias or usrloc entry directs the call to a different SIP UA or router via IP or a different SIP [sub]domain for further processing, it should presume it has all information to resolve this call fully itself, and recurse onto itself to resolve any names inside its own domain. Basically, the DNS model for domain authority.

- Jim