Thanks Daniel, Setting the missed call flag again in my failure_route blocks did the trick.
Cheers, Stephen Dodge From: Daniel-Constantin Mierla [mailto:mico...@gmail.com] Sent: 03 April 2012 12:27 To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List Cc: Stephen Dodge (Bistech) Subject: Re: [SR-Users] Acc Module - logging forked calls. Hello, try setting again the missed calls flag for each step of serial forking -- I cannot remember by hart if it needs rearming or not... Alternative, try to use acc_db_request(...) to missed_calls table in failure route. Cheers, Daniel On 4/2/12 3:52 PM, Stephen Dodge (Bistech) wrote: Hello, We currently use the acc module to capture information to generate CDR missed call info. I have now introduced serial forking and I would like to see if I can improve how accounting is working for missed calls. I am using the following configuration. # turn accounting on for all new calls if (is_method("INVITE")){ setflag(1); # do accouting setflag(2); # missed calls record_route(); } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")){ setflag(1); # do accounting setflag(3); # even if the transaction fails xdbg("## BISNET ## - RTPPROXY CHECK \n"); # clear any rtpproxy sessions in progress unforce_rtp_proxy(); } I've noticed that accounting for missed calls is generated for the main branch (1st destination) only, whether this is a 486 response or a 408 on expiry of the 'fr_inv_timer'. After a receiving a failure another destination is created/tried by the script, we are allowing up to 4 serial forks. I do see the 183 message for each fork and if the call is answered then the acc table is updated correctly. How can I log the missed call response for each fork, or only log the final failure message for the call? Logging failed transactions seems to put them into the main acc table and not the missed call table which I would have expected. Thanks, Steve. ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/ ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
