<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE table PUBLIC "-//iptel.org//DTD DBSchema V1.0//EN" 
  "http://iptel.org/dbschema/dtd/1.0/dbschema.dtd" [

<!ENTITY % entities SYSTEM "entities.xml">
%entities;

]>

<table xmlns:db="http://docbook.org/ns/docbook">
  <name>missed_calls</name>
  <description>
	<db:para>
	  SER stores accounting records in missed_calls table. When configured to
	  account transactions, SER will write one row per transaction into this
	  table. The table is never read by SER, SER only writes into this
	  table. SERWeb can query the table to display the list of missed
	  calls. Only transactions that finished with a negative reply (3xx, 4xx,
	  5xx) are written to this table.
	</db:para>
	<db:para>
	  SERWeb queries the table when displaying the list of missed calls of a
	  user.
	</db:para>
  </description>
  <version>4</version>
  
  <column id="mc.id">
	<name>id</name>
	<type>int</type>
	<type db="mysql">INT AUTO_INCREMENT</type>
	<type db="postgres">SERIAL</type>
	<type db="dbtext">int,auto</type>
	<description>
	  ID that uniquely identifies each row. This is automatically generated by
	  the database server. This id is useful for post processing.
	</description>
  </column>

  <column id="mc.server_id">
	<name>server_id</name>
	<type>int</type>
	<default>0</default>
	<description>
	  ID of the SIP server that generated the record.
	</description>
  </column>
  
  <column id="mc.from_uid">
	<name>from_uid</name>
	<type>string</type>
	<size>&id_len;</size>
	<null/>
	<description>
	  The UID (Unique ID) of the originator of transaction (the caller). For
	  local users this will be one of UIDs from user_attrs table, for 3rd
	  party users this column will be empty (as they have no uid assigned on
	  the server).
	</description>
  </column>
  <column id="mc.to_uid">
	<name>to_uid</name>
	<type>string</type>
	<size>&id_len;</size>
	<null/>
	<description>
	  This is the UID (Unique ID) of the target (the callee) of the
	  request. For local users this will be one of UIDs from user_attrs table,
	  for 3rd party users this column will be empty (as they have no uid
	  assigned on the server).
	</description>
  </column>
  
  <column>
	<name>to_did</name>
	<type>string</type>
	<size>&id_len;</size>
	<null/>
	<description>
	  The unique identifier of destination domain in SER. This identifier is
	  usually based on the domain name present in the Request-URI of the SIP
	  request. This value is empty for outbound requests to 3rd party domains.
	</description>
  </column>
  
  <column>
	<name>from_did</name>
	<type>string</type>
	<size>&id_len;</size>
	<null/>
	<description>
	  The unique identifier of originating domain in SER. This identifier is
	  usually based on the domain name present in the From header field of the
	  SIP request. This value is empty for inbound requests from 3rd party
	  domains.
	</description>
  </column>
  
  <column>
	<name>sip_from</name>
	<type>string</type>
	<size>&hf_len;</size>
	<null/>
	<description>
	  The body of the From header field, including display name and all
	  parameters URI and header field parameters.
	</description>
  </column>
  
  <column>
	<name>sip_to</name>
	<type>string</type>
	<size>&hf_len;</size>
	<null/>
	<description>
	  The body of the To header field, including display name and all
	  parameters URI and header field parameters.
	</description>
  </column>
  
  <column>
	<name>sip_status</name>
	<type>int</type>
	<null/>
	<description>
	  The status code of the final SIP reply that finished the transaction
	  being accounted.
	</description>
  </column>
  
  <column>
	<name>sip_method</name>
	<type>string</type>
	<size>&method_len;</size>
	<null/>
	<description>
	  The method of the SIP request that created the transaction being
	  accounted.
	</description>
  </column>
  
  <column>
	<name>in_ruri</name>
	<type>string</type>
	<size>&uri_len;</size>
	<null/>
	<description>
	  Inbound Request-URI. This is the value of the Request-URI as received by
	  SER from the previous (upstream) element (typically generated by the SIP
	  phone of the caller).
	</description>
  </column>
  
  <column>
	<name>out_ruri</name>
	<type>string</type>
	<size>&uri_len;</size>
	<null/>
	<description>
	  Outbound Request-URI. This is the value of the Request-URI when the
	  request leaves SER, i.e. after applying all the modifications and
	  rewrites in the configuration file of SER. The next downstream element
	  (typically the SIP phone of the callee) will see exactly this value of
	  the Request-URI.
	</description>
  </column>
  
  <column>
	<name>from_uri</name>
	<type>string</type>
	<size>&uri_len;</size>
	<null/>
	<description>
	  The SIP URI extracted from From header field. This is just the plain SIP
	  URI without display name and header field parameters (if From header
	  field contains angle brackets then this column contains the string
	  between the angle brackets).
	</description>
  </column>
  
  <column>
	<name>to_uri</name>
	<type>string</type>
	<size>&uri_len;</size>
	<null/>
	<description>
	  The SIP URI extracted from To header field. This is just the plain SIP
	  URI without display name and header field parameters (if To header field
	  contains angle brackets then this column contains the string between the
	  angle brackets).
	</description>
  </column>
  
  <column id="mc.sip_callid">
	<name>sip_callid</name>
	<type>string</type>
	<size>&uri_len;</size>
	<null/>
	<description>
	  The value of the Call-ID header field. This value uniquely identifies a
	  call.
	</description>
  </column>
  
  <column id="mc.sip_cseq">
	<name>sip_cseq</name>
	<type>int</type>
	<null/>
	<description>
	  CSeq number.
	</description>
  </column>
  
  <column id="mc.username">
	<name>digest_username</name>
	<type>string</type>
	<size>&user_len;</size>
	<null/>
	<description>
	  The value of username attribute from authorized (verified by the server)
	  digest credentials.
	</description>
  </column>
  
  <column id="mc.realm">
	<name>digest_realm</name>
	<type>string</type>
	<size>&uri_len;</size>
	<null/>
	<description>
	  The value of realm attribute from authorized (verified by the server)
	  digest credentials.
	</description>
  </column>
  
  <column>
	<name>from_tag</name>
	<type>string</type>
	<size>128</size>
	<null/>
	<description>
	  The value of the tag parameter in From header field.
	</description>
  </column>
  
  <column>
	<name>to_tag</name>
	<type>string</type>
	<size>128</size>
	<null/>
	<description>
	  The value of the tag parameter in To header field.
	</description>
  </column>
  
  <column>
	<name>src_ip</name>
	<type>unsigned int</type>
	<null/>
	<description>
	  The source IP address of the packet containing the SIP request that
	  created the transaction.
	</description>
  </column>
  
  <column>
	<name>src_port</name>
	<type>unsigned short</type>
	<null/>
	<description>
	  The source port of the packet containing the SIP request that created
	  the transaction.
	</description>
  </column>

  <column>
	<name>request_timestamp</name>
	<type>datetime</type>
	<description>
	  The date and time of the request arrival to the proxy.
	</description>
  </column>
  
  <column>
	<name>response_timestamp</name>
	<type>datetime</type>
	<description>
	  The date and time when the final response was sent out.
	</description>
  </column>
  
  <column>
	<name>flags</name>
	<type>unsigned int</type>
	<default>0</default>
	<description>
	  Various flags. The meaning of bits in the flags field is described in
	  the table below.
	  <db:note>
		<db:simpara>
		  Note that several flags below have no meaning in this table and are
		  only presented for completeness, because the flags column has
		  identical meaning of flags across most tables in the database.
		</db:simpara>
	  </db:note>
	  <db:table><db:title>possible missed_calls flags</db:title>
		<db:tgroup cols="4">
		  <db:thead>
			<db:row>
			  <db:entry>Bit</db:entry>
			  <db:entry>Hex value</db:entry>
			  <db:entry>Flag</db:entry>
			  <db:entry>Description</db:entry>
			</db:row>
		  </db:thead>
		  <db:tbody>
			<db:row>
			  <db:entry>0</db:entry>
			  <db:entry>0x00000001</db:entry>
			  <db:entry>FOR_SER</db:entry>
			  <db:entry>
				If set then SER will load the row (not applicable in this
				table).
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>1</db:entry>
			  <db:entry>0x00000002</db:entry>
			  <db:entry>DISABLED</db:entry>
			  <db:entry>
				The data represented by the row is temporarily disabled, which
				means it stays in the database but no applications use it.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>2</db:entry>
			  <db:entry>0x00000004</db:entry>
			  <db:entry>CANONICAL</db:entry>
			  <db:entry>
				The URI or domain name is canonical. When displaying the URI
				of the user or name of a domain then this entry should be
				used.  Not applicable in this table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>3</db:entry>
			  <db:entry>0x00000008</db:entry>
			  <db:entry>ALLOWED_TO</db:entry>
			  <db:entry>
				The URI represented by this row can be used in The Request-URI
				or To header field. In other words the user will be reachable
				under this URI and can use it as an alias. Not applicable in
				this table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>4</db:entry>
			  <db:entry>0x00000010</db:entry>
			  <db:entry>ALLOWED_FROM</db:entry>
			  <db:entry>
				The user identified by uid can use this URI in From header
				field. Not applicable in this table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>5</db:entry>
			  <db:entry>0x00000020</db:entry>
			  <db:entry>FOR_SERWEB</db:entry>
			  <db:entry>
				The data represented by the row is for SERWeb. This is
				currently used in credentials table only where the flags
				allows to keep different credentials for digest authentication
				in SIP and for SERWeb authentication. Not applicable in this
				table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>6</db:entry>
			  <db:entry>0x00000040</db:entry>
			  <db:entry>PENDING</db:entry>
			  <db:entry>
				The account owning the piece of data has not been activated
				yet. Not applicable in this table, this is mainly used in
				credentials table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>7</db:entry>
			  <db:entry>0x00000100</db:entry>
			  <db:entry>DELETED</db:entry>
			  <db:entry>
				The row has been scheduled for deletion.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>8</db:entry>
			  <db:entry>0x00000200</db:entry>
			  <db:entry>CALLER_DELETED</db:entry>
			  <db:entry>
				The accounting record has been scheduled for deletion by the
				caller. The row can be deleted once both the caller and callee
				schedule the record for deletion. A single record can be
				shared by two users and thus both of them must schedule it for
				deletion before it can be physically deleted.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>9</db:entry>
			  <db:entry>0x00000400</db:entry>
			  <db:entry>CALLEE_DELETED</db:entry>
			  <db:entry>
				The accounting record has been scheduled for deletion by the
				callee. The row can be deleted once both the caller and callee
				schedule the record for deletion. A single record can be
				shared by two users and thus both of them must schedule it for
				deletion before it can be physically deleted.
			  </db:entry>
			</db:row>
		  </db:tbody>
		</db:tgroup>
	  </db:table>
	</description>
  </column>
  
  <column>
	<name>attrs</name>
	<type>string</type>
	<size>255</size>
	<null/>
	<description>
	  The value of selected attributes used during processing of the
	  transaction/call on the server.
	</description>
  </column>
  
  <index>
	<name>mc_id_key</name>
	<unique/>
	<colref linkend="mc.server_id"/>
	<colref linkend="mc.id"/>
  </index>
  
  <index role="serweb">
	<name>mc_cid_key</name>
	<colref linkend="mc.sip_callid"/>
  </index>
  
  <index role="serweb">
	<name>mc_to_uid</name>
	<colref linkend="mc.to_uid"/>
  </index>
</table>
