operation.sgml

用来作为linux中SIP SERVER,完成VOIP网络电话中服务器的功能

+------+-----+---------------------+
| john | int | 2002-12-08 02:09:20 |
+------+-----+---------------------+
			    </screen>
			</para>
	    </section> <!-- access control -->
	    <section>
		<title>Accounting</title>
			<para>
			    In some scenarios, like termination of calls in PSTN, SIP administrators
			    may wish to keep track of placed calls. <application moreinfo="none">ser</application>
			    can be configured to report on completed transactions. Reports are sent
			    by default to <application moreinfo="none">syslog</application> facility.
			    Support for RADIUS and mysql accounting exists as well.
			</para>
			<para>
			    Note that <application moreinfo="none">ser</application> is no way 
			    call-stateful. It reports on completed transactions, i.e., after 
			    a successful call set up is reported, it drops any call-related 
			    state. When a call is terminated, transactional state for BYE request
			    is created and forgotten again after the transaction completes.
			    This is a feature and not a bug -- keeping only transactional
			    state allows for significantly higher scalability. It is then
			    up to the accounting application to correlate call initiation
			    and termination events.
			</para>
			<para>
			    To enable call accounting, tm and acc modules need to be loaded,
			    requests need to be processed statefully and labeled for
			    accounting. That means, if you want a transaction to be reported,
				the initial request must have taken the path 
				"<command>setflag(X)</command>, <command>t_relay</command>"
				in <application>ser</application> script. X must have the
				value configured in <varname>acc_flag</varname>
				configuration option.
			</para>
			<para>
				Also note, that by default only transactions that initiate
				a SIP dialog (typically INVITE) visit a proxy server.
				Subsequent transactions are exchanged directly between
				end-devices, do not visit proxy server and cannot be
				reported. To be able to report on subsequent transactions,
				you need to force them visit proxy server by turning 
				record-routing on. 
			</para>
			<para>
				
			    <example>
				<title>Configuration with Enabled Accounting</title>
				<programlisting format="linespecific">
&accountingexample;
				</programlisting>
			    </example>
			</para>
	    </section> <!-- accounting -->
	    <section>
		<title>Reliability</title>

			<para>
			    It is essential to guarantee continuous
			    service operation even under erroneous conditions, 
			    such as host or network failure. The major issue in such
			    situations is transfer of operation to a backup
			    infrastructure and making clients use it.
			</para>
			<para>
			    The SIP standard's use of DNS SRV records has been
			    explicitly constructed to handle with server failures.
			    There may be multiple servers responsible for a domain
			    and referred to by DNS. If it is impossible to communicate
			    with a primary server, a client can proceed to another one.
			    Backup servers may be located in a different geographic
			    area to minimize risk caused by areal operational
			    disasters: lack of power, flooding, earthquake, etc.
			    <note>
				<sidebar>
				    <para>Unless there are redundant DNS
				    servers, fail-over capability cannot be guaranteed.
				    </para>
				</sidebar>
			    </note>
			    Unfortunately, at the moment of writing this documentation
			    (end of December 2002) only very few SIP products
			    actually implement the DNS fail-over mechanism. Unless
			    networks with SIP devices supporting this mechanism are
			    built, alternative mechanisms must be used to force 
			    clients to use backup servers. Such a mechanism is
			    disconnecting primary server and replacing it with
			    a backup server locally.
			    It unfortunately precludes geographic dispersion and
			    requires network multihoming to avoid dependency on
			    single IP access. Another method is to update DNS
			    when failure of the primary server is detected.
			    The primary drawback of this method is its latency:
			    it may take long time until all clients learn to use
			    the new server.
			</para>
			<para>
			    The easier part of the redundancy story is replication of 
			    <application moreinfo="none">ser</application>
			    data. <application moreinfo="none">ser</application>
			    relies on replication capabilities of its back-end database.
			    This works with one exception: user location database.
			    User location database is a frequently accessed table,
			    which is thus cached in server's memory to improve
			    performance. Back-end replication does not affect
			    in-memory tables, unless server reboots. To facilitate
			    replication of user location database, 
			    server's SIP replication feature must be enabled
			    in parallel with back-end replication.
			</para>
			<para>
			    The design idea of replication of user location database
			    is easy: Replicate any successful REGISTER requests to
			    a peer server. To assure that digest credentials can
			    be properly verified, both servers need to use the same
			    digest generation secret and maintain synchronized time.
			    A known limitation of this method is it does not replicate
			    user contacts entered in another way, for example using
			    web interface through FIFO server.
			    The following script example shows configuration of
			    a server that replicates all REGISTERs.
			    <example>
				<title>Script for Replication of User Contacts</title>
				<programlisting format="linespecific">
&replicateexample;				    
				</programlisting>
			    </example>
			</para>
	    </section> <!-- reliability -->
	    <section>
		<title>Stateful versus Stateless Forwarding</title>
		<para>
		    <application moreinfo="none">ser</application> allows both stateless
		    and stateful request processing. This memo explains what are pros and cons of
		    using each method. The rule of thumb is "stateless for scalability,
		    stateful for services". If you are unsure which you need, stateful
		    is a safer choice which supports more usage scenarios.
		</para>
			<para>
			    Stateless forwarding with the
			    <command moreinfo="none">forward(uri:host, uri:port)</command> action
			    guarantees high scalability. It withstands high load and
			    does not run out of memory. A perfect use of stateless forwarding
			    is load distribution.
			</para>
			<para>
			    Stateful forwarding using the <command moreinfo="none">t_relay()</command>
			    action is known to scale worse. It can quickly run out of memory and
			    consumes more CPU time. Nevertheless, there are scenarios which are
			    not implementable without stateful processing. In particular:
			    <itemizedlist>
				<listitem>
				    <para>
					<emphasis>Accounting</emphasis> requires stateful processing
					to be able to collect transaction status and issue a single
					report when a transaction completes.
				    </para>
				</listitem>
				<listitem>
				    <para>
					<emphasis>Forking</emphasis> only works with stateful forwarding.
					Stateless forwarding only forwards to the default URI out of the
					whole destination set.
				    </para>
				</listitem>
				<listitem>
				    <para>
					<emphasis>DNS resolution</emphasis>. DNS resolution may be
					better served with stateful processing. If a request is forwarded
					to a destination whose address takes long time to resolve,
					a server process is blocked and unresponsive. Subsequent 
					request retransmissions from client will cause other processes
					to block too if requests are processed statelessly. As a result,
					<application moreinfo="none">ser</application> will quickly
					run out of available processes. With stateful forwarding,
					retransmissions are absorbed and do not cause blocking of
					another process.
				    </para>
				</listitem>
				<listitem>
				    <para>
					<emphasis>Forwarding Services</emphasis>. All sort of services 
					with the "forward_on_event" logic, which rely on 
					<command moreinfo="none">t_on_failure</command> tm
					action must be processed statefully.
				    </para>
				</listitem>
			<listitem>
			    <para>
				<emphasis>
				    Fail-over.
				</emphasis>
				If you wish to try out another destination, after a primary destination
				failed you need to use stateful processing. With stateless processing
				you never know with what status a forwarded request completed downstream
				because you immediately release all processing information after the 
				request is sent out. 

				<note>
				    <para>
					Positive return value of stateless
					<command moreinfo="none">forward</command> action only indicates that
					a request was successfully sent out, and does not gain any knowledge
					about whether it was successfully received or replied. Neither does
					the return value of
					the stateful <command moreinfo="none">t_relay</command> action family
					gain you this knowledge. However, these actions store transactional
					context with which includes original request and allows you to
					take an action when a negative reply comes back or a timer strikes.
					See <xref linkend="replyprocessingsection"> for an example script 
					which launches another
					branch if the first try fails.
				    </para>
				</note>

			    </para>
			</listitem>
			    </itemizedlist>
			</para>
	    </section> <!-- stateful vs. stateless -->
	    <section>
		<title>Serving Multiple Domains</title>
			<para>
			    <application moreinfo="none">ser</application> can be configured to
			    serve multiple domains. To do so, you need to take the following steps:
			    <orderedlist>
				<listitem id="createtable">
				    <para>
					Create separate subscriber and location database table
					for each domain served and name them uniquely.
				    </para>
				</listitem>
				<listitem>
				    <para>
					Configure your script to distinguish between multiple
					served domains. Use regular expressions for domain
					matching as described in <xref linkend="redomainmatching">.
				    </para>
				</listitem>
				<listitem>
				    <para>
					Update table names in usrloc and auth actions to reflect
					names you created in <xref linkend="createtable">.
				    </para>
				</listitem>
				
			    </orderedlist>
			</para>
			<para>
				The latest <application>SER</application> release includes automated
				multidomain management which greatly automates maintenance of multiple	
				domains. Ask our technical support for more help.
			</para>
	    </section> <!-- multiple domains -->
	    <section id="missedcalls">
		<title>Reporting Missed Calls</title>
			<para>
			    <application moreinfo="none">ser</application> can report missed
			    calls via <application moreinfo="none">syslog</application> facility
			    or to mysql. Mysql reporting can be utilized by 
			    <application moreinfo="none">ser</application>'s 
			    complementary web-interface, <application moreinfo="none">serweb</application>.
			    (See more in <xref linkend="serweb">).
			</para>
			<para>
			    Reporting on missed calls is enabled by acc module.
			    There are two cases, on which you want to report. The first
			    case is when a callee is off-line. The other case is when
			    a user is on-line, but call establishment fails. There
			    may be many failure reasons (call cancellation, inactive phone,
			    busy phone, server timer, etc.), all of them leading to
			    a negative (>=300) reply sent to caller. The acc module
			    can be configured to issue a missed-call report whenever
			    a transaction completes with a negative status. Two following
			    script fragment deals with both cases.
			</para>
			<para>
			    First, it reports
			    on calls missed due to off-line callee status
			    using the <command moreinfo="none">acc_request</command>
			    action. The action is wrapped in transactional
			    processing (<command moreinfo="none">t_newtran</command>)
			    to guarantee that reports are not
			    duplicated on receipt of retransmissions.
			    </para>
			<para>
			    Secondly, transactions to on-line users are marked
			    to be reported on failure. That is what the 
			    <command moreinfo="none">setflag(3)</command> action
			    is responsible for, along with the configuration option
			    "log_missed_flag". This option configures <application moreinfo="none">ser</application>
			    to report on all transactions, which were marked
			    with flag 3.			   
			    <programlisting format="linespecific">
loadmodule("modules/tm/tm.so");
loadmodule("modules/acc/acc.so");
....
# if a call is labeled using setflag(3) and is missed, it will
# be reported
...
modparam("acc", "log_missed_flag", 3 );
if (!lookup("location")) {
     # call invitations to off-line users are reported using the
     # acc_request action; to avoid duplicate reports on request
     # retransmissions, request is processed statefully (t_newtran,
     # t_reply)
     if ((method=="INVITE" || method=="ACK") && t_newtran() ) {
          t_reply("404", "Not Found");
	  acc_request("404 Not Found");
          break;
     };
     # all other requests to off-line users are simply replied
     # statelessly and no reports are issued
    sl_send_reply("404", "Not Found");
    break;
} else {
     # user on-line; report on failed transactions; mark the
     # transaction for reporting using the same number as 
     # configured above; if the call is really missed, a report
     # will be issued
     setflag(3);
     # forward to user's current destination
     t_relay();
     break;
};
			    </programlisting>
			    
			</para>
	    </section> <!-- missed calls -->
	    <section>
		<title>NAT Traversal</title>
		<para>
		    NATs are worst things that ever happened to SIP. These devices
		    are very popular because they help to conserve IP address space
		    and save money charged for IP addresses. Unfortunately, they
		    translate addresses in a way which is not compatible with SIP.
		    SIP advertises receiver addresses in its payload. The advertised
		    addresses are invalid out of NATed networks. As a result,
		    SIP communication does not work across NATs without extra
		    effort.
		</para>
		<para>
		    There are few methods that may be deployed to traverse NATs.
		    How proper their use is depends on the deployment scenario.
		    Unfortunately, all the methods have some limitations and
		    there is no straight-forward solution addressing all
		    scenarios. Note that none of these methods takes explicit
		    support in <application moreinfo="none">ser</application>.
		</para>
		<para>
		    The first issue is whether SIP users are in control of 
		    their NATs. If not (NATs are either operated by ISP or
		    they are sealed to prevent users setting them up), the
		    only method is use of a STUN-enabled phone. STUN is 
		    a very simple protocol used to fool NAT in such a way,
		    they permit SIP sessions. Currently, we are aware of
		    one softphone (kphone) and one hardphone (snom) with
		    STUN support, other vendors are working on STUN support
		    too. Unfortunately, STUN gives no NAT traversal
		    guarantee -- there are types of NATs, so called
		    symmetric NATs, over which STUN fails to work.
		    <note>
			<para>
			    There is actually yet another method to address
			    SIP-unaware, user-uncontrolled NATs. It is based
			    on a proxy server, which relays all signaling and
			    media and mangles packets to make them more
			    NAT-friendly. The very serious problem with this
			    method is it does not scale.
			</para>
		    </note>
		</para>
		<para>
		    If users are in control of their own NAT, as typically residential
		    users are, they can still use STUN. However, they may use other