Hi everybody,
during the latest days there were committed some last pending changes before freezing the CVS for starting the test period before the next release,
Here is a short summary of these changes:
0) Core
- forward and send functions merged by including the protocol, host and port into a single parameter like [proto:]host[:port]. Aligned to t_relay() and t_forward() format and NAPTR lookup enabled also - provides TLS client domains (name/socket based) and more script config capabilities
1) Accounting
bugs fixed: - the "missed call" report will display as outgoing uri exactly the RURI used for that branch - the accounting report will display as outgoing uri the RURI of the winning branch
behaviour fix: - the "missed call" flag has effect only on the next serial fork - once triggered to report a missed call (a serial fork step ended), the flag is automatically reset by module. To catch the potential "missed call" reports due next serial forks, you need to re-arm the flag from failure route. This behaviour gives full control over what branches should be or not accounted as "missed calls".
- null pseudo-variable values are stored as "n/a" to keep consistency with acc format
2) TM module
- TM API exports a new function for making public the selected branch (how the winning branch is selected must be transparent for the other modules)
- fixed the branch selection algorithm - if the transaction was cancelled, the "487 Request cancelled" reply will have priority and it will be sent to UAC.
-t_replicate() takes as parameter a SIP URI instead of a destination (in order to align the format as for append_branch() ). -t_replicate() uses the set branches to perform parallel replication to multiple destinations.
3) Registrar / USRLOC
- usrloc is able to detect retransmissions based on Callid and Cseq. The retransmission detection is controlled via the new "cseq_delay" module parameter. REGISTER retransmissions (inside the cseq_delay interval) will not generate error, but they will be accepted and properly replied without any update on the location status. This solves the problem of retransmissions without having a statefull processing on requests.
4) TLSOPS module
The idea was to have some TLS related functions which can be used in the routing script to check TLS parameters. There is only one function implemented : is_peer_verified() This function returns 1 if the message is received via TLS and the peer was verified during TLS connection handshake, otherwise it returns -1. All information from the certificate is exported to the script via pseudo-variables.
Regards, Bogdan
Bogdan-Andrei Iancu writes:
behaviour fix:
- the "missed call" flag has effect only on the next serial fork -
once triggered to report a missed call (a serial fork step ended), the flag is automatically reset by module. To catch the potential "missed call" reports due next serial forks, you need to re-arm the flag from failure route.
assuming the above holds true for radius_missed_flag, then how about radius_flag? does it remain set for all serial branches? if so, why would its behavior be different from radius_missed_flag?
-- juha
Bogdan-Andrei Iancu writes:
- the "missed call" flag has effect only on the next serial fork - once triggered to report a missed call (a serial fork step ended), the flag is automatically reset by module. To catch the potential "missed call" reports due next serial forks, you need to re-arm the flag from failure route. This behaviour gives full control over what branches should be or not accounted as "missed calls".
based on that, i understand that it is not possible to report missed call only in case all forks fail. if so, then i guess during post processing of accounting records, one needs to reject failure reports if there also exists a positive report for the same call.
-- juha
Bogdan-Andrei Iancu writes:
- the "missed call" flag has effect only on the next serial fork - once triggered to report a missed call (a serial fork step ended), the flag is automatically reset by module. To catch the potential "missed call" reports due next serial forks, you need to re-arm the flag from failure route. This behaviour gives full control over what branches should be or not accounted as "missed calls".
coming back to this, what i would like to do is to have an accounting report to be send only upon:
* TMCB_RESPONSE_OUT -- a final reply was sent out (either local * or proxied) -- there is nothing more you can change from * the callback, it is good for accounting-like uses.
and if at that moment both radius_flag and radius_missed_flag (or log_flag and log_missed_flag) are set and final reply is negative (>= 400), then only one report should be sent out.
-- juha
Hi Juha,
normally only one missed call report should be generated per fork sequence. I'm still trying to reproduce what you are reporting, but not successful so fat - still getting only one report. Are you using the latest CVS version?
Accounting is done on TMCB_RESPONSE_OUT. if you set the accounting flag, the call report will be triggered at that point - by default only successful transactions are reported; to get also the negative ones, you need to set the failed_transaction flag also.
Missing calls is a different story - there can be more than one report per transaction if serial fork was done.
To achieve your scenario, you need to set the accounting flag (to get the call report if successful) and the missed call flag (to get a missed call report(s) if the call fails).
regards, bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
- the "missed call" flag has effect only on the next serial fork - once triggered to report a missed call (a serial fork step ended), the flag is automatically reset by module. To catch the potential "missed call" reports due next serial forks, you need to re-arm the flag from failure route. This behaviour gives full control over what branches should be or not accounted as "missed calls".
coming back to this, what i would like to do is to have an accounting report to be send only upon:
- TMCB_RESPONSE_OUT -- a final reply was sent out (either local
- or proxied) -- there is nothing more you can change from
- the callback, it is good for accounting-like uses.
and if at that moment both radius_flag and radius_missed_flag (or log_flag and log_missed_flag) are set and final reply is negative (>= 400), then only one report should be sent out.
-- juha
Bogdan-Andrei Iancu writes:
normally only one missed call report should be generated per fork sequence. I'm still trying to reproduce what you are reporting, but not successful so fat - still getting only one report. Are you using the latest CVS version?
i should be, but looks like sf is down again and i can't check.
Accounting is done on TMCB_RESPONSE_OUT. if you set the accounting flag, the call report will be triggered at that point - by default only successful transactions are reported; to get also the negative ones, you need to set the failed_transaction flag also.
as i told, i don't have failed_transactions flag set. i have been reading acc_mod.c code. call back function does the following tests:
static void tmcb_func( struct cell* t, int type, struct tmcb_params *ps ) { if (type&TMCB_RESPONSE_OUT) { acc_onreply( t, ps->req, ps->rpl, ps->code); } else if (type&TMCB_E2EACK_IN) { acc_onack( t, t->uas.request, ps->req, ps->code); } else if (type&TMCB_ON_FAILURE) { on_missed( t, ps->req, ps->rpl, ps->code); } else if (type&TMCB_RESPONSE_IN) { acc_onreply_in( t, ps->req, ps->rpl, ps->code); } }
does that mean that if invite times out, both on_missed and acc_onreply are called, on_missed, when 408 is triggered by proxy and acc_onreply when 408 is sent out to the caller? on the other hand, acc_onreply itself calls both on_missed and acc_rad_reply.
To achieve your scenario, you need to set the accounting flag (to get the call report if successful) and the missed call flag (to get a missed call report(s) if the call fails).
i have those two flags set and i get two reports if call fails.
-- juha
Juha Heinanen writes:
static void tmcb_func( struct cell* t, int type, struct tmcb_params *ps ) { if (type&TMCB_RESPONSE_OUT) { acc_onreply( t, ps->req, ps->rpl, ps->code); } else if (type&TMCB_E2EACK_IN) { acc_onack( t, t->uas.request, ps->req, ps->code); } else if (type&TMCB_ON_FAILURE) { on_missed( t, ps->req, ps->rpl, ps->code); } else if (type&TMCB_RESPONSE_IN) { acc_onreply_in( t, ps->req, ps->rpl, ps->code); } }
i commented out TMCB_ON_FAILURE part and now got only one call missed report, which must have come from acc_onreply.
-- juha
-
Bogdan-Andrei Iancu -
Juha Heinanen