[SR-Users] how to use "t_drop_replies" but keep the last reply for acc

[Daniel-Constantin Mierla]

Forgot to say that you should also look at failed transaction flag parameter in acc, it should handle your needs, iirc.

Daniel-Constantin Mierla
http://www.asipto.com

On 10 Nov 2012, at 08:41, Daniel-Constantin Mierla <miconda at gmail.com> wrote:

> Hello,
> 
> With latest stable you should be able to execute acc_db_request() for the reply in onreply_route. Then it should take the totag from reply.
> 
> When doing in failure route, it processes the incoming invite that has no totag.
> 
> Cheers,
> Daniel
> 
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
> 
> On 8 Nov 2012, at 10:17, Uri Shacked <ushacked at gmail.com> wrote:
> 
>> Hi,
>> OK, i do not use drop reply.
>> I do fork the call to the secondary destination.
>> Still, I need this (busy/no_answer) reply to be inserted into the acc table.
>> Ho do i do that?
>> I tried acc_db_request() but the to_tag is missing and the sip_code is missing as well.
>> How do i force the sip_code to be the one i generated or received? how do i use the to_tag from the last reply i got (183 for example)?
>> I know i can probably save the to_tag and the sip_code, use update with sqlops or on the other hand do everything in the database afterwards - but this is very tricky and i think not efficient.
>> So, any way to write the reply i do not send to the caller to the DB with the 183 to_tag and the relevant sip_code?
>> Thanks,
>> Uri
>> 
>> 
>>  
>> On Wed, Nov 7, 2012 at 7:35 PM, Uri Shacked <ushacked at gmail.com> wrote:
>> Thanks.
>> I am doing the reroutes on the failure route. I am using drop reply to prevent the caller from receiving the 4xx reply from the first destination. If i would just t_relay with the new deatination, the 4xx will not be forward to the caller?
>> 
>> בתאריך 7 בנוב 2012 18:46, מאת "Klaus Darilion" <klaus.mailinglists at pernau.at>:
>> 
>> As I said I can not comment on the accounting, but dropping replies to forward the request to another destination is the wrong approach. Sequential forking should be done in a failure route.
>> 
>> Klaus
>> 
>> On 07.11.2012 17:31, Uri Shacked wrote:
>> So if I wont use the drop reply I might get what I need?
>> 
>> בתאריך 7 בנוב 2012 18:10, מאת "Klaus Darilion"
>> <klaus.mailinglists at pernau.at <mailto:klaus.mailinglists at pernau.at>>:
>> 
>>     Ingoring accounting, such "sequential forking" scenarios are usually
>>     solved by having the forkin logic in a failure-route.
>> 
>>     - 1st callee sends 486
>>     - failure route is executed, if winning response is 486, set the new
>>     destination and t_relay().
>> 
>>     I do not know how this single transaction with 2 branches is
>>     reflected in the acc table, but I guess you can implement any acc
>>     behavior using manual accounting.
>> 
>>     regards
>>     Klaus
>> 
>>     On 07.11.2012 16:29, Uri Shacked wrote:
>> 
>>         To be more accurate - I am using the "t_set_fr()" it generates
>>         408 and
>>         sends cancel to the destination.
>> 
>>         This is the case that i do not see a final reply for the first
>>         invite.
>> 
>> 
>> 
>>         On Wed, Nov 7, 2012 at 5:24 PM, Uri Shacked <ushacked at gmail.com
>>         <mailto:ushacked at gmail.com>
>>         <mailto:ushacked at gmail.com <mailto:ushacked at gmail.com>>> wrote:
>> 
>>              Hi,
>>              I am trying to make an option of "route when no answer" or
>>         " route
>>              when busy".
>>              What I am doing is checking the reply and if "busy", for
>>         example, I
>>              use "t_drop_replies". Then, I set the new number and
>>         route[relay] again.
>>              On the accdb table, I get the first invite with 183 and
>>         after that
>>              the second invite with 183 and with 200.
>>              I would like to do exactly what i do, but would like to see
>>         on the
>>              accdb the 486 reply from the first invite.
>>              how do i do it?
>>              BR,
>>              Uri
>> 
>> 
>> 
>> 
>>         _________________________________________________
>>         SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>>         mailing list
>>         sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>         http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121110/ab704455/attachment-0001.htm>