You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
kamailio/lib/srdb2/schema/acc.xml

465 lines
13 KiB

<?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>acc</name>
<description>
<db:para>
SER stores accounting records in acc 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 placed calls.
</db:para>
<db:para>
SER records sucessful transactions (those replied with a 2xx final
response) into this table. SER never reads or updates rows in the table,
it only inserts new rows into the table. This table can potentially get
big. There will be 1-3 rows per call, depending on the configuration of
SER.
</db:para>
<db:para>
SERWeb queries the table when displaying the list of placed calls of a
subscriber.
</db:para>
</description>
<version>4</version>
<column id="acc.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 automaticaly generated
by the database server. This id is useful for post processing.
</description>
</column>
<column id="acc.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="acc.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="acc.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
usualy 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
usualy based on the domain name present in the From header field of
the SIP request. This value is empty for inbound reqeusts 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="acc.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="acc.sip_cseq">
<name>sip_cseq</name>
<type>int</type>
<null/>
<description>
CSeq number.
</description>
</column>
<column id="acc.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="acc.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 acc 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>acc_id_key</name>
<unique/>
<colref linkend="acc.server_id"/>
<colref linkend="acc.id"/>
</index>
<index role="serweb">
<name>acc_cid_key</name>
<colref linkend="acc.sip_callid"/>
</index>
<index role="serweb">
<name>acc_from_uid</name>
<colref linkend="acc.from_uid"/>
</index>
<index role="serweb">
<name>acc_to_uid</name>
<colref linkend="acc.to_uid"/>
</index>
</table>