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
