Hi,
I need SER to sequentially try 3 URIs, while using a unique token for the 1st and 3rd UAS and no token for the 2nd one. I have tried using 'append_hf' and 'remove_hf' functions to add and remove header fields, but it does not exactly do what I need. Calls to "remove_hf" do not make any difference. I guess 'remove_hf' only removes header values from the received INVITE message. I have tried using the CPL logic below. Any help would be very appreciated.
Best Regards, Dmitry
route { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.1\r\n"); t_on_failure("1"); t_relay(); # Want the 1st UAS to receive only the token above - WORKS! .. }
failure_route[1] { .. remove_hf("P-OSP-Auth-Token"); t_on_failure("2"); t_relay(); # Want the 2nd UAS to not receive any tokens - does NOT work, it receives the token from the 1st attempt .. }
failure_route[2] { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.3\r\n"); t_on_failure("2"); t_relay(); # Want the 3rd UAS to receive only the token above - does NOT work, it receives both tokens from the 1st and 3rd attempts .. }
I commited patch which adds support for branch_route sections, this is what you are looking for, it allows you to modify each branch individually:
http://lists.iptel.org/pipermail/serdev/2005-August/005371.html
Jan.
On 02-09-2005 15:28, Dmitry Isakbayev wrote:
Hi,
I need SER to sequentially try 3 URIs, while using a unique token for the 1st and 3rd UAS and no token for the 2nd one. I have tried using 'append_hf' and 'remove_hf' functions to add and remove header fields, but it does not exactly do what I need. Calls to "remove_hf" do not make any difference. I guess 'remove_hf' only removes header values from the received INVITE message. I have tried using the CPL logic below. Any help would be very appreciated.
Best Regards, Dmitry
route { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.1\r\n"); t_on_failure("1"); t_relay(); # Want the 1st UAS to receive only the token above - WORKS! .. }
failure_route[1] { .. remove_hf("P-OSP-Auth-Token"); t_on_failure("2"); t_relay(); # Want the 2nd UAS to not receive any tokens - does NOT work, it receives the token from the 1st attempt .. }
failure_route[2] { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.3\r\n"); t_on_failure("2"); t_relay(); # Want the 3rd UAS to receive only the token above - does NOT work, it receives both tokens from the 1st and 3rd attempts .. }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Jan!
Dmitry talked about sequential forking and failure routes. Does branch_routes also works when called sequentially from failure routes?
regards klaus
Jan Janak wrote:
I commited patch which adds support for branch_route sections, this is what you are looking for, it allows you to modify each branch individually:
http://lists.iptel.org/pipermail/serdev/2005-August/005371.html
Jan.
On 02-09-2005 15:28, Dmitry Isakbayev wrote:
Hi,
I need SER to sequentially try 3 URIs, while using a unique token for the 1st and 3rd UAS and no token for the 2nd one. I have tried using 'append_hf' and 'remove_hf' functions to add and remove header fields, but it does not exactly do what I need. Calls to "remove_hf" do not make any difference. I guess 'remove_hf' only removes header values from the received INVITE message. I have tried using the CPL logic below. Any help would be very appreciated.
Best Regards, Dmitry
route { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.1\r\n"); t_on_failure("1"); t_relay(); # Want the 1st UAS to receive only the token above - WORKS! .. }
failure_route[1] { .. remove_hf("P-OSP-Auth-Token"); t_on_failure("2"); t_relay(); # Want the 2nd UAS to not receive any tokens - does NOT work, it receives the token from the 1st attempt .. }
failure_route[2] { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.3\r\n"); t_on_failure("2"); t_relay(); # Want the 3rd UAS to receive only the token above - does NOT work, it receives both tokens from the 1st and 3rd attempts .. }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 06-09-2005 17:06, Klaus Darilion wrote:
Hi Jan!
Dmitry talked about sequential forking and failure routes. Does branch_routes also works when called sequentially from failure routes?
Yes, it should work too, but you need to call t_on_branch again from any failure_route, because the flag is automatically reset after use.
Jan.
regards klaus
Jan Janak wrote:
I commited patch which adds support for branch_route sections, this is what you are looking for, it allows you to modify each branch individually:
http://lists.iptel.org/pipermail/serdev/2005-August/005371.html
Jan.
On 02-09-2005 15:28, Dmitry Isakbayev wrote:
Hi,
I need SER to sequentially try 3 URIs, while using a unique token for the 1st and 3rd UAS and no token for the 2nd one. I have tried using 'append_hf' and 'remove_hf' functions to add and remove header fields, but it does not exactly do what I need. Calls to "remove_hf" do not make any difference. I guess 'remove_hf' only removes header values from the received INVITE message. I have tried using the CPL logic below. Any help would be very appreciated.
Best Regards, Dmitry
route { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.1\r\n"); t_on_failure("1"); t_relay(); # Want the 1st UAS to receive only the token above - WORKS! .. }
failure_route[1] { .. remove_hf("P-OSP-Auth-Token"); t_on_failure("2"); t_relay(); # Want the 2nd UAS to not receive any tokens - does NOT work, it receives the token from the 1st attempt .. }
failure_route[2] { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.3\r\n"); t_on_failure("2"); t_relay(); # Want the 3rd UAS to receive only the token above - does NOT work, it receives both tokens from the 1st and 3rd attempts .. }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Jan and Klaus,
Thank you for pointing me to the new 'branch_routes' functionality. Sounds like it is going to be a good solution for my case. I will need to take a close look at how it works.
If I call a module function from the "branch_routes" block, can it figure out its branch index?
Best Regards, Dmitry
----- Original Message ----- From: "Jan Janak" jan@iptel.org To: "Klaus Darilion" klaus.mailinglists@pernau.at Cc: "Dmitry Isakbayev" isakdim@gmail.com; serusers@lists.iptel.org Sent: Tuesday, September 06, 2005 11:28 AM Subject: Re: [Serusers] Appending different authorization tokens for every branch.
On 06-09-2005 17:06, Klaus Darilion wrote:
Hi Jan!
Dmitry talked about sequential forking and failure routes. Does branch_routes also works when called sequentially from failure routes?
Yes, it should work too, but you need to call t_on_branch again from any failure_route, because the flag is automatically reset after use.
Jan.
regards klaus
Jan Janak wrote:
I commited patch which adds support for branch_route sections, this is what you are looking for, it allows you to modify each branch individually:
http://lists.iptel.org/pipermail/serdev/2005-August/005371.html
Jan.
On 02-09-2005 15:28, Dmitry Isakbayev wrote:
Hi,
I need SER to sequentially try 3 URIs, while using a unique token for the 1st and 3rd UAS and no token for the 2nd one. I have tried using 'append_hf' and 'remove_hf' functions to add and remove header fields, but it does not exactly do what I need. Calls to "remove_hf" do not make any difference. I guess 'remove_hf' only removes header values from the received INVITE message. I have tried using the CPL logic below. Any help would be very appreciated.
Best Regards, Dmitry
route { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.1\r\n"); t_on_failure("1"); t_relay(); # Want the 1st UAS to receive only the token above - WORKS! .. }
failure_route[1] { .. remove_hf("P-OSP-Auth-Token"); t_on_failure("2"); t_relay(); # Want the 2nd UAS to not receive any tokens - does NOT work, it receives the token from the 1st attempt .. }
failure_route[2] { .. append_hf("P-OSP-Auth-Token: open.settlement.token.number.3\r\n"); t_on_failure("2"); t_relay(); # Want the 3rd UAS to receive only the token above - does NOT work, it receives both tokens from the 1st and 3rd attempts .. }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 06-09-2005 12:19, Dmitry Isakbayev wrote:
Hi Jan and Klaus,
Thank you for pointing me to the new 'branch_routes' functionality. Sounds like it is going to be a good solution for my case. I will need to take a close look at how it works.
If I call a module function from the "branch_routes" block, can it figure out its branch index?
No, but you can test for the value of the Request-URI.
Jan.
-
Dmitry Isakbayev -
Jan Janak -
Klaus Darilion