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
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@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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
So if I wont use the drop reply I might get what I need? בתאריך 7 בנוב 2012 18:10, מאת "Klaus Darilion" <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@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@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@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? בתאריך 7 בנוב 2012 18:46, מאת "Klaus Darilion" <klaus.mailinglists@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@pernau.at <mailto:klaus.mailinglists@**pernau.atklaus.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@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@lists.sip-router.org <mailto:sr-users@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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@pernau.at <mailto:klaus.mailinglists@**pernau.atklaus.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@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@lists.sip-router.org <mailto:sr-users@lists.sip-**router.org sr-users@lists.sip-router.org> http://lists.sip-router.org/__**cgi-bin/mailman/listinfo/sr-__** usershttp://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users< http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 11/08/2012 04:17 AM, Uri Shacked wrote:
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.
It seems to me this is your only option.
We dropped use of 'acc' entirely in favour of writing CDRs in a fully home-grown way with 'sqlops', so that we could do exactly what we want. I would not describe this process as "inefficient".
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@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@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@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@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@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@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>
Forgot to say that you should also look at failed transaction flag parameter in acc, it should handle your needs, iirc.
Daniel-Constantin Mierla http://www.asipto.com
On 10 Nov 2012, at 08:41, Daniel-Constantin Mierla miconda@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 ushacked@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@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@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@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@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@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>
"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 miconda@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 ushacked@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@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@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@pernau.at <mailto:klaus.mailinglists@**pernau.atklaus.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@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@lists.sip-router.org <mailto:sr-users@lists.sip-**router.org sr-users@lists.sip-router.org> http://lists.sip-router.org/__**cgi-bin/mailman/listinfo/sr-__* *usershttp://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users< http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 11/07/2012 12:35 PM, Uri Shacked 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?
That is correct; when you create a new branch, the replies from the old branches are not forwarded to the caller. Only the final reply from the final branch (or an alternate reply of your choosing) will be.
-
Alex Balashov -
Daniel-Constantin Mierla -
Klaus Darilion -
Uri Shacked