<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
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).<br>
<br>
For example:<br>
<tt><br>
</tt>
<blockquote><tt>ser.cfg has line: alias="domain.com"<br>
Callee is <a class="moz-txt-link-rfc2396E" href="mailto:alias1@domain.com">"alias1@domain.com"</a></tt><tt><br>
SER user alias <a class="moz-txt-link-rfc2396E" href="mailto:alias1@domain.com">"alias1@domain.com"</a> -> <a class="moz-txt-link-rfc2396E" href="sip:alias2@domain.com">"sip:alias2@domain.com"</a> ->
<a class="moz-txt-link-rfc2396E" href="sip:user@domain.com">"sip:user@domain.com"</a><br>
SER usrloc entry exists for <a class="moz-txt-link-rfc2396E" href="mailto:user@domain.com">"user@domain.com"</a> ->
<a class="moz-txt-link-rfc2396E" href="sip:user@[IP-of-user's-phone]">"sip:user@[IP-of-user's-phone]"</a><br>
/etc/hosts file has entry in the form of: <br>
1.2.3.4 siprouter siprouter.domain.com domain.com<br>
CALL WORKS<br>
<br>
However, change /etc/host file entry to: <br>
1.2.3.4 siprouter siprouter.domain.com <br>
(remove alias for whole domain)<br>
CALL FAILS<br>
<br>
Other, more simple SER user aliases WORK in BOTH scenereos: <br>
SER user alias <a class="moz-txt-link-rfc2396E" href="mailto:somealias@domain.com">"somealias@domain.com"</a> ->
<a class="moz-txt-link-rfc2396E" href="sip:someuser@domain.com">"sip:someuser@domain.com"</a><br>
SER usrloc exists for <a class="moz-txt-link-rfc2396E" href="mailto:someuser@domain.com">"someuser@domain.com"</a> ->
<a class="moz-txt-link-rfc2396E" href="sip:someuser@[IP-of-user's-phone]">"sip:someuser@[IP-of-user's-phone]"</a><br>
CALL WORKS<br>
This is whether the "domain.com" /etc/hosts alias exists or not.<br>
</tt></blockquote>
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). <br>
<br>
Note, that "ser.cfg" DOES have a line alias="domain.com", so SER should
know that it is responsible for this SIP domain. <br>
<br>
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 ?<br>
<br>
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.<br>
<br>
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). <br>
<br>
The "good" fix is to use a DNS SRV entry (at least I hope this would
fix both SER problems mentioned here).<br>
<br>
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.<br>
<br>
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.<br>
<br>
- Jim<br>
<br>
<pre class="moz-signature" cols="78">--
+---------------------------------------------------------------------------+
| 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: <a class="moz-txt-link-abbreviated" href="mailto:jimb@jsbc.cc">jimb@jsbc.cc</a> ICQ UIN: 1695089 |
+---------------------------------------------------------------------------+
| Reply problems ? Turn off the "sign" function in email prog. Blame MS. |
+---------------------------------------------------------------------------+
</pre>
</body>
</html>