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

[Uri Shacked]

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/20121108/715e3801/attachment.htm>