> > "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 <mico...@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 <ushac...@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 <ushac...@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.mailingli...@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.mailingli...@pernau.at >>>> <mailto:klaus.mailinglists@**pernau.at<klaus.mailingli...@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 <ushac...@gmail.com >>>> <mailto:ushac...@gmail.com> >>>> <mailto:ushac...@gmail.com <mailto:ushac...@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@lists.sip-router.org <mailto:sr-us...@lists.sip-** >>>> router.org <sr-users@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> >>>> > >>>> >>>> >
_______________________________________________ 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