[OpenSIPS-Users] ACC and failed calls

[Alexander Mustafin]

OK, Răzvan, maybe my avp’s are null at this moment - much more important, that really sip code not presented in this row. Completely filled row for this leg creates in missed_call table. I.e. 2 rows creates for one leg with error - one in acc table and one in missed_calls.


Best regards,
Alexander Mustafin
mustafin.aleksandr at gmail.com




02 дек. 2013 г., в 15:07, Răzvan Crainea <razvan at opensips.org> написал(а):

> Hi, Alexander!
> 
> Are you sure you are populating all the multi_leg_info AVPs for each
> leg? In your case, you have two legs, therefore you should populate each variable two times - once for the initial leg and second for the redirect.
> 
> Best regards,
> 
> Razvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 11/30/2013 05:07 AM, Alexander Mustafin wrote:
>> Hi, Răzvan.
>> 
>> Thank you for this hint!
>> 
>> I set multi-leg acc support now, and it’s almost works )))
>> 
>> 1) If first GW drop my call and return error - ACC generate row in table
>> for this leg, BUT sip_code is 200 (not error code)
>> 2) I set modparam("acc", "multi_leg_info»,…) with avp I would to store
>> in database, but almost all columns are empty for unsuccessfull leg -
>> for other legs they are present.
>> 
>> 
>> Best regards,
>> Alexander Mustafin
>> mustafin.aleksandr at gmail.com <mailto:mustafin.aleksandr at gmail.com>
>> 
>> 
>> 
>> 
>> 29 нояб. 2013 г., в 14:44, Răzvan Crainea <razvan at opensips.org
>> <mailto:razvan at opensips.org>> написал(а):
>> 
>>> Hi, Alexander!
>>> 
>>> If you want to have multiple rows for each leg, then you should use
>>> multi-leg acc support[1]. Note that you should not use the CDR flag,
>>> since you are doing old two-steps accounting.
>>> 
>>> [1] http://www.opensips.org/html/docs/modules/1.8.x/acc#multi-call-legs
>>> 
>>> Best regards,
>>> 
>>> Razvan Crainea
>>> OpenSIPS Core Developer
>>> http://www.opensips-solutions.com
>>> 
>>> On 11/28/2013 02:36 PM, Alexander Mustafin wrote:
>>>> If first gateway in drouting return error - I need a CDR with sip code
>>>> of error. Then, if next gw is setup the call  - I need a CDR, after BYE
>>>> message.
>>>> 
>>>> First attempt - generate one row INVITE in the table (with error code),
>>>> and second attempt generate two rows  - INVITE and BYE
>>>> 
>>>> I believe that it should work like that!
>>>> 
>>>> Best regards,
>>>> Alexander Mustafin
>>>> mustafin.aleksandr at gmail.com <mailto:mustafin.aleksandr at gmail.com>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 28 нояб. 2013 г., в 15:42, Alexander Mustafin
>>>> <mustafin.aleksandr at gmail.com <mailto:mustafin.aleksandr at gmail.com>>
>>>> написал(а):
>>>> 
>>>>> Hi, Razvan!
>>>>> 
>>>>> I’m tried set  ACC_FAILED in places, where call may be failed. In
>>>>> request route too.
>>>>> 
>>>>> Best regards,
>>>>> Alexander Mustafin
>>>>> mustafin.aleksandr at gmail.com <mailto:mustafin.aleksandr at gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 28 нояб. 2013 г., в 15:35, Răzvan Crainea <razvan at opensips.org
>>>>> <mailto:razvan at opensips.org>> написал(а):
>>>>> 
>>>>>> Hi, Alexander!
>>>>>> 
>>>>>> Have you tried setting the ACC_FAILED flag in the request route?
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Razvan Crainea
>>>>>> OpenSIPS Core Developer
>>>>>> http://www.opensips-solutions.com <http://www.opensips-solutions.com/>
>>>>>> 
>>>>>> On 11/28/2013 10:35 AM, Alexander Mustafin wrote:
>>>>>>> Hello!
>>>>>>> 
>>>>>>> I need to store all CDRs for all calls, but some failed calls are
>>>>>>> not to
>>>>>>> handled by ACC.
>>>>>>> 
>>>>>>> modparam("acc", "failed_transaction_flag", "ACC_FAILED»)
>>>>>>> 
>>>>>>> failure_route[MISSED_CALL] {
>>>>>>>       if (t_check_status("[4|5][0-9][0-9]")) {
>>>>>>> setflag(ACC_FAILED);
>>>>>>> }
>>>>>>> }
>>>>>>> 
>>>>>>> But call which rejected with 503 (example) error is missed in acc
>>>>>>> table.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Alexander Mustafin
>>>>>>> mustafin.aleksandr at gmail.com
>>>>>>> <mailto:mustafin.aleksandr at gmail.com><mailto:mustafin.aleksandr at gmail.com>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> 
>>> 
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131203/bb0a68cf/attachment.htm>