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

[Uri Shacked]

>
> "Forgot to say that you should also look at failed transaction flag
> parameter in acc, it should handle your needs, iirc."
> when i use t_branch_timeout() and generates self 408. then reroute to
> another destination, the flag was set to 3 and didnt wrote to DB the 408.
>
>
 "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."

i use t_branch_timeout()  and that can not be executed on the reply
route......

anyway, what i did was saving the $tt on the 18X reply and afterwards use
sqlops to insert the data i needed on the acc table.

thanks a lot for the help.

>
>
> 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@**pernau.at<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 <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><
>>>> 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/20121111/bfbcde59/attachment.htm>