:

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 &lt;ushacked(a)gmail.com > <mailto:ushacked@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(a)lists.sip-router.org > http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http:/… > >

:

:

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.

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 &lt;ushacked(a)gmail.com&gt; 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 &lt;ushacked(a)gmail.com&gt; 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" &lt;klaus.mailinglists(a)pernau.at&gt;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" > &lt;klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@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 &lt;ushacked(a)gmail.com > <mailto:ushacked@gmail.com> > <mailto:ushacked@gmail.com <mailto:ushacked@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(a)lists.sip-router.org <mailto: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> > >

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?