10 Nov
2012
10 Nov
'12
2:41 a.m.
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(a)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(a)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(a)pernau.at>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(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 <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>