alternatives too. One of them is to replace their NAT with		    a SIP-aware NAT. Such NATs have built-in SIP awareness,		    that patches problems caused by address translations. Prices		    of such devices are getting low and there are available		    implementations (Intertex, Cisco/PIX). No special support		    in phones is needed.		</para>		<para>		    Other emerging option is UPnP. UPnP is a protocol that allows		    phones to negotiate with NAT boxes. You need UPnP support in		    both, NAT and phones. As UPnP NATs are quite affordable,		    costs are not an obstacle. Currently, we are aware of one		    SIP phone (SNOM) with UPnP support.		</para>		<para>		    Geeks not wishing to upgrade their firewall to a SIP-aware or		    UPnP-enabled one may try to configure static address translation.		    That takes phones with configuration ability to use fixed port		    numbers and advertise outside address in signaling. Cisco phones		    have this capability, for example. The NAT devices need to		    be configured to translate outside port ranges to the 		    ranges configured in phones.		    		</para>	    </section> <!-- NAT traversal -->		<section>		<title>Using Only Latest User's Contact for Forwarding		</title>			<para>				In some scenarios, it may be beneficial only to use only one				registered contact per user. If that is the case, setting				registrar module's parameter <varname>append_branches</varname>				to 1 will eliminate forking and forward all requests only				to a single contact. If there are multiple contacts, a contact				with highest priority is chosen. This can be changed to				the "freshest" contact by setting module parameter's				<varname>desc_time_order</varname> to 1.			</para>		</section>	    <section>		<title>Authentication Policy: Prevention of Unauthorized Domain 		    Name Use in From and More</title>		<para>		    Malicious users can claim a name of domain, to which they do 		    not administratively belong, in From header field. This		    behavior cannot be generally prevented. The reason is		    that requests with such a faked header field do not need		    to visit servers of the domain in question. However, if they		    do so, it is desirable to assure that users claiming		    membership in a domain are actually associated with it.		    Otherwise the faked requests would be relayed and appear		    as coming from the domain, which would increase		    credibility of the faked address and decrease credibility of		    the proxy server.		</para>		<para>		    Preventing unauthorized domain name use in relayed requests 		    is not difficult.		    One needs to authenticate each request with name of the		    served domain in From header field. To do so, one can		    search for such a header field using <command moreinfo="none">search</command>		    action (textops module) and force authentication if the		    search succeeds.		    <note>			<para>			    A straight-forward solution might be to authenticate			    ALL requests. However, that only works in closed			    networks in which all users have an account in the			    server domain. In open networks, it is desirable to permit			    incoming calls from callers from other domains without			    any authentication. For example, a company may wish			    to accept calls from unknown callers who are			    new prospective customers.			    			</para>		    </note>		    <programlisting format="linespecific"># does the user claim our domain "foo.bar" in From?if (search("^(f|From):.*foo.bar")) {        # if so, verify credential	if (!proxy_authorize("foo.bar", "subscriber")) {               # don't proceed if credentials broken; challenge	      proxy_challenge("foo.bar", "0");	      break;        };};		    </programlisting>		</para>		<para>		    In general, the authentication policy may be very rich. You may not		    forget each request deserves its own security and you need to 		    decide whether it shall be authenticated or not. As mentioned		    above, in closed networks, you may want to authenticate absolutely 		    every request. That however prohibits traffic from users from		    other domains. A pseudo-example of a reasonable policy is attached:		    it looks whether a request is registration, it claims to originate		    from our domain in From header field, or is a local request to		    another domain.		    <programlisting format="linespecific"># (example provided by Michael Graff on [serusers] mailing listif (to me):    if register          www_authorize or fail if not a valid register          done    if claiming to be "From" one of the domains I accept registrations for          proxy_authorize          done    if not to me (I'm relaying for a local phone to an external address)          proxy_authorize          done		    </programlisting>		</para>		<para>		    You also may want to apply additional restriction to how		    digest username relates to usernames claimed in From and		    To header fields. For example, the <command moreinfo="none">check_to</command>		    action enforces the digest id to be equal to username		    in To header fields. That is good in preventing someone		    with valid credentials to register as someone else		    (e.g., sending a REGISTER with valid credentials of		    "joe" and To belonging to "alice"). Similarly,		    <command moreinfo="none">check_from</command> is used		    to enforce username in  from to equal to digest id.		    <note>			<para>			    There may be a need for a more complex relationship			    between From/To username and digest id. For example,			    providers with an established user/password database			    may wish to keep using it, whereas permitting users			    to claim some telephone numbers in From. To address			    such needs generally, there needs to be a 1:N mapping			    between digest id and all usernames that are acceptable			    for it. This is being addressed in a newly contributed			    module "domain", which also addresses more generally			    issues of domain matching for multidomain scenarios.			</para>		    </note>		</para>		<para>		    Other operational aspect affecting the authentication policy		    is guarding PSTN gateways (see <xref linkend="acl">). There		    may be destinations that are given away for free whereas		    other destinations may require access control using		    group membership, to which  authentication is a prerequisite.		</para>	    </section> <!-- authentication policy, faked froms -->	    <section>		<title>Connecting to PBX Voicemail Using a Cisco Gateway</title>		<para>		    In some networks, administrators may wish to utilize their		    PBX voicemail systems behind PSTN gateways. There is a practical problem		    in many network settings: it is not clear for whom a call to		    voicemail is. If voicemail is identified by a single number,		    which is then put in INVITE's URI, there is no easy way to		    learn for whom a message should be recorded. PBX voicemails		    utilize that PSTN protocols signal the number of originally		    called party. If you wish to make the PBX voicemail work,		    you need to convey the number in SIP and translate it in		    PSTN gateways to its PSTN counterpart.		</para>		<para>		    There may be many different ways to achieve this scenario. Here		    we describe the proprietary mechanism Cisco gateways use and how to 		    configure <application moreinfo="none">ser</application> to		    make the gateways happy. Cisco gateways expect the number		    of originally called party to be located in proprietary		    <varname>CC-Diversion</varname> header field. When a SIP 		    INVITE sent via a PSTN gateway to PBX voicemail has number		    of originally called party in the header field, the voicemail		    system knows for whom the incoming message is. That is at least		    true for AS5300/2600 with Cisco IOS 12.2.(2)XB connected to		    Nortel pbxs via PRI. (On the other hand, 12.2.(7b) is known		    not to work in this scenario.)		</para>		<para>		    <application moreinfo="none">ser</application> needs then to		    be configured to append the <varname>CC-Diversion</varname>		    header field name for INVITEs sent to PBX voicemail.		    The following script shows that: when initial forwarding		    fails (nobody replies, busy is received, etc.), a new branch		    is initiated to the pbx's phone number. 		    <command moreinfo="none">append_urihf</command> is used to		    append the <varname>CC-Diversion</varname> header field. It		    takes two parameters: prefix, which includes header name,		    and suffix which takes header field separator. 		    <command moreinfo="none">append_urihf</command> inserts		    original URI between those two.		    <example>			<title>Forwarding to PBX/Voicemail via Cisco Gateways</title>			<programlisting format="linespecific">&ccdiversion;			</programlisting>		    </example>		    		</para>	    </section>	</section> <!-- howtos -->	<section>	    <title>Troubleshooting</title>	    <para>		This section gathers practices how to deal with errors		known to occur frequently. To understand how to watch		SIP messages, server logs, and in general how to		troubleshoot, read also <xref linkend="operationalpractices">. 	    </para>	    <qandaset>		<qandaentry>		    <question>			<para>			SIP requests are replied by <application>ser</application> with			"483 Too Many Hops" or "513 Message Too Large"		        </para>		    </question>		    <answer>			<para>			    In both cases, the reason is probably an error in			    request routing script which caused an infinite loop.			    You can easily verify whether this happens by			    watching SIP traffic on loopback interface. A typical			    reason for misrouting is a failure to match local			    domain correctly. If a server fails to recognize			    a request for itself, it will try to forward it			    to current URI in believe it would forward them			    to a foreign domain. Alas, it forwards the request			    to itself again. This continues to happen until			    value of max_forwards header field reaches zero			    or the request grows too big. Solutions is easy:			    make sure that domain matching is correctly			    configured. See <xref linkend="domainmatching">			    for more information how to get it right.			</para>		    </answer>		    		</qandaentry>		<qandaentry>					    <question>			        			<para>						    Windows Messenger authentication fails.			</para>		    </question>		    <answer>			<anchor id="msmbug">			<para>			    The most likely reason for this problem is a bug			    in Windows Messenger. WM only authenticates if			    server name in request URI equals authentication			    realm. After a challenge is sent by SIP server,			    WM does not resubmit the challenged request at all			    and pops up authentication window again.			    If you want to authenticate WM, you need to			    set up your realm value to equal server name.			    If your server has no name, IP address can be used			    as realm too. The realm value is configured in				scripts as the first parameter of all				<command>{www|proxy}_{authorize|challenge}</command>				actions.			</para>		    </answer>		</qandaentry>		<qandaentry>		    <question>			<para>			    On a multihomed host, forwarded messages carry other 			    interface in Via than used for sending, or messages 			    are not sent and an error log is issued "invalid 			    sendtoparameters one possible reason is the server 			    is bound to localhost".			</para>		    </question>		    <answer>			<anchor id="mhomed">			<para>			    Set the configuration option <varname>mhomed</varname>			    to "1". <application moreinfo="none">ser</application>			    will then attempt to calculate the correct interface.			    It's not done by default as it degrades performance			    on single-homed hosts or multi-homed hosts that are			    not set-up as routers.			</para>		    </answer>		</qandaentry>		<qandaentry>		    <question>			<para>			    I receive "ERROR: t_newtran: transaction already in process" in my logs.			</para>		    </question>		    <answer>			<para>			    That looks like an erroneous use of tm module in script.			    tm can handle only one transaction per request. If you			    attempt to instantiate a transaction multiple times,			    <application moreinfo="none">ser</application> will complain.			    Anytime any of <command moreinfo="none">t_newtran</command>,			    <command moreinfo="none">t_relay</command> or 			    <command moreinfo="none">t_relay_to_udp</command> actions is			    encountered, tm attempts to instantiate a transaction.			    Doing so twice fails. Make sure that any of this			    commands is called only once during script execution.			</para>		    </answer>		</qandaentry>		<qandaentry>		    <question>			<para>			    I try to add an alias but 			    <command moreinfo="none">serctl</command>			    complains that table does not exist.			</para>		    </question>		    <answer>			<para>			    You need to run <application moreinfo="none">ser</application>			    and use the command			    <command moreinfo="none">lookup("aliases")</command>			    in its routing script. That's because the table 			    of aliases is			    stored in cache memory for high speed. The cache			    memory is only set up when the 			    <application moreinfo="none">ser</application>			    is running and configured to use it. If that is			    not the case, 			    <application moreinfo="none">serctl</application>			    is not able to manipulate the aliases table.			</para>		    </answer>		</qandaentry>	    <qandaentry>		<question>		    <para>I started <application>ser</application> with			<varname>children=4</varname> but many more processes			were started. What is wrong?			</para>		    </question>		<answer>		    <para>			That's ok. The <varname>children</varname> parameter defines			how many children should process each transport protocol in			parallel. Typically, the server listens to multiple protocols			and starts other supporting processes like timer or FIFO			server too. Call <application>serctl ps</application> to watch			running processes.			</para>		    </answer>		</qandaentry>	    <qandaentry>		<question>		    <para>			I decided to use a compiled version of <application>ser</application>			but it does not start any more.			</para>		    </question>		<answer>		    <para>			You probably kept the same configuration file, which tries to load modules			from the binary distribution you used previously. Make sure that modules			paths are valid and point to where you compiled <application>ser</application>.			Also, watch logs for error messages "ERROR: load_module: could not open 			module".			</para>		    </answer>		</qandaentry>	    	    </qandaset>	</section> <!-- troubleshooting -->    </chapter> <!-- operation -->