Hello, The below problem was because of an error in the configuration. Basically you have to set the missed_call flag every time before going into the failure route. It works well when configured like that !!
Thanks for all the help. --- Jayesh On Fri, Dec 2, 2011 at 2:51 PM, Jayesh Nambiar <[email protected]>wrote: > Hi Bogdan, > Just ran into another challenge while testing this. Basically I try 3 > carriers for a single call. So what happens now is, the first failed call > gets inserted into the missed_calls table but the second and third one does > not enter. Moreover, if the first call fails and before the second carrier > connects if the caller sends a CANCEL, the row with 487 status also does > not get entered into the missed_calls table. > How do I make sure that all failed transactions get inserted into the > missed_call table and successful call get inserted into the acc table !! > Thanks, > > --- Jayesh > > > On Tue, Nov 29, 2011 at 12:03 AM, Jayesh Nambiar <[email protected]>wrote: > >> Thanks for the super suggestion. This has just made it very simple and >> isolated !! >> >> --- Jayesh >> >> >> On Mon, Nov 28, 2011 at 5:21 PM, Bogdan-Andrei Iancu <[email protected] >> > wrote: >> >>> ** >>> Hello Jayesh, >>> >>> For your purpose + needs, I would rather suggest to use, instead of >>> multi-leg accounting, standard accounting + missed calls accounting - so in >>> ACC table you will get a single record showing calls from caller to GWn >>> (successful one), while in MISSED_CALLS table you will get one record per >>> failure (with the corresponding reply info). Probably you can use db_extra >>> to push more than the standard info into the accounting records. >>> >>> Regards, >>> Bogdan >>> >>> >>> On 11/28/2011 12:57 PM, Jayesh Nambiar wrote: >>> >>> Hi All, >>> I use failure_routes to failover the calls to multiple carriers. So if >>> 1st carrier rejects the call, I route it to another carrier for the call to >>> get completed. Now, I need the accounting of first carrier also in the acc >>> table. Basically I need to know that this call was rejected from the 1st >>> carrier and got connected on the second carrier. I am able to insert all >>> the carrier related details in the acc table using multi-leg info >>> parameter. But I get stuck on the standard acc columns like sip_code, >>> sip_reason, to_tag etc. >>> When the call gets connected on second carrier, the sip_code and >>> sip_reason for the first row also shows 200 OK when in reality the sip_code >>> and sip_reason for the first attempt was 503 Service Unavailable. Is it >>> possible to maintain those standard values also in some variable/AVPs and >>> insert appropriate values in appropriate rows?? >>> >>> I also tried a different approach of not using acc module and using >>> avp_db_query for accounting on reply_routes. Basically this will insert a >>> record for every initial INVITE and all BYEs after a reply for the method >>> is received. Something like this gives me more control on what is to be >>> inserted according to my requirements: >>> >>> if(loose_route()) { >>> if(is_method("BYE")) { >>> t_on_reply("1"); >>> } >>> t_relay(); >>> } >>> >>> if(is_method("INVITE")) { >>> <my logic> >>> t_on_reply("1"); >>> t_relay(); >>> } >>> >>> onreply_route[1] { >>> if(status =~ [2-6][0-9][0-9]) { >>> avp_db_query("insert into acc (sip_method, >>> sip_to_tag,sip_callid,sip_code,sip_reason, calling_party, called_party, >>> source_ip, dst_ip) values ('$rm', '$tt', '$ci', '$rs', '$rr', '$fU', >>> '$avp(called_party)', '$avp(source_ip)', '$avp(dst_ip)' )"); >>> } >>> } >>> I set the appropriate AVPs like $avp(called_party), $avp(dst_ip) etc >>> after the initial INVITEs according to my requirements. These are my >>> questions: >>> >>> 1) First and foremost will this method insert proper INVITE and BYE for >>> accounting purpose? >>> 2) How much roughly will be the penalty on efficiency as compared to >>> using the acc module? >>> 3) Can AVP module take advantage of parameters like query_buffer_time >>> and query_flush_time for performance reasons? >>> 4) Can I use prepared_statements while inserting using avp_db_query for >>> performance reasons? >>> >>> Any help and suggestions regarding the above queries are very much >>> appreciated. >>> Thanks in advance. >>> >>> --- Jayesh >>> >>> >>> _______________________________________________ >>> Users mailing >>> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> -- >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> OpenSIPS solutions and "know-how" >>> >>> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
