accountingThis is the page where YOU add your most wanted SERi features or modules! Please feel free to edit this page. See a more detailed list of wishlist items on the tracker (items on this wishlist will end up in the tracker when they are detailed enough to do actual coding). New groups can also be added. This wishlist is used for evaluating what to focus on for future releases. In order to know the general interest of a feature, you can also vote for features. Just add an * in parenthesis behind the feature, and please only add one... to_did D Yes Yes Yes Domain ID of the destination domain. request_timestamp x Yes Yes Yes The timestamp of SIP request arrival. When used this field contains the timestamp of the SIP request arrival. The time is in UTC. The timestamp of the SIP request arrival is necessary if you need to calculate the duration of the call precisely. The beginning of the call is denoted by arrival of 200 OK to INVITE, response_timestamp field contains the timestamp of 200 OK to INVITE. The end of the call, however, is denoted by the arrival of BYE request. It does not matter if and when a final reply to BYE comes. BYE request cannot be refused and you typicaly want to terminate the call at the same time you hang up the receiver on your SIP phone, and this is the time when your SIP phone generates BYE. digest_username u Yes Yes Yes Username from verified digest credentials. If the SIP message contained digest credentials and the credentials have been successfuly verified, that means www_authenticate or proxy_authenticate was successful, then this field will contain the username parameter from the credentials. Digest credentials that have not been succesfuly verified by SERi are ignored, that means that if the SIP request contained digest credentials but you did call neither www_authenticate nor proxy_authenticate then this field will be either empty or missing. INVITE sip:callee@iptel.org SIP/2.0 sip_to t Yes Yes Yes The entire body of To header field. sip_to accounting record contains the entire From header field body, including the name part, SIP URIi and all URI and header field parameters. This field is useful mainly for presentation, for example, in the list of missed or placed calls. There you might want to show users even the name of the caller, which is usualy present in the name part. The value of this header field is not suitable for machine processing because it contains the header field body unparsed. If you need just SIP URI from the header field or the value of the tagi parameter then you can use from_uri and from_tag accounting fields instead. INVITE sip:callee@iptel.org SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5060 Max-Forwards: 70 From: "Caller" <sip:caller@iptel.org>;tagi=76ff7a07 To: <sip:callee@iptel.org> source_ip p Yes Yes Yes The source IP of SIP request. This field contains the source IP of the datagram carrying the SIP request. This is either the IP of the user agent that generated the request or NATi. outbound_ruri o Yes Yes Yes inbound_ruri i Yes Yes Yes INVITE sip:callee@iptel.org SIP/2.0 sip_from f Yes Yes Yes The field contains the body of From header field. sip_from accounting record contains the entire From header field body, including the name part, SIP URIi and all URI and header field parameters. This field is useful mainly for presentation, for example, in the list of missed or placed calls. There you might want to show users even the name of the caller, which is usualy present in the name part. The value of this header field is not suitable for machine processing because it contains the header field body unparsed. If you need just SIP URI from the header field or the value of the tagi parameter then you can use from_uri and from_tag accounting fields instead. INVITE sip:callee@iptel.org SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5060 Max-Forwards: 70 From: "Caller" <sip:caller@iptel.org>;tagi=76ff7a07 to_tag d Yes Yes Yes The value of tagi parameter from To header field. This accounting record field contains the value of the tagi parameter from To header field. Because the original request that creates the dialogi or transactioni does not contain tag parameter in To header field, the value of this field is extracted from the finaly reply. The value of this field is used to match INVITE and BYE transactionsi that belong to the same call. sip_callid c Yes Yes Yes Field containing Call-ID value. This accounting record field contains the value of the SIP Call-ID The value of Call-ID header field is used to match the INVITE INVITE sip:callee@iptel.org SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5060 Max-Forwards: 70 From: "Caller" <sip:caller@iptel.org>;tagi=76ff7a07 To: <sip:callee@iptel.org> The acc_db module can be used to implement database based accounting of SIP transactionsi. The module uses the internal SERi database API and thus it can be used with any database supported by SER, such as mysql, postgres, dbtext, or flatstore. The accounting module works with SIP transactions. For every transactioni that is marked with a special flag the accounting module will extract some information from SIP request and associated responses and write it in the database. The accounted data contains all information that is necessary to calculate biling information, such as the URIi of the callee and caller, date and time of the SIP request arrival and so on. Because the module needs information from both the SIP request and final response, the module does not write anything in the database when an INVITE comes, for example, but all information accumulated from the INVITE and 200 OK to the INVITE will be written at once when 200 OK comes. The data from the INVITE and 200 OK is written in the database as single row and the row contains all information extracted from the SIP transaction.  |
Navigation |
