Folks,
We are currently trying to implement owerflow routing with sip and b2bua. Our network setup looks like the following (two GWs here is for simplicity, actually there would be dozens of them):
--------- /--|PSTN GW|-\ ---- ----------------- ------- /~~~~~~/ --------- \ /~~~~~~~~\ |UA|--|PROXY/REGISTRAR|--|B2BUA|--<IP CLOUD> <PSTN CLOUD> ---- ----------------- ------- ______/\ --------- / ________/ --|PSTN GW|-/ ---------
Since potentially each destination in the PSTN could be reached through more than one GW we would like to use that for adding some more robustness to the system, beause from time to time some of gateways might be unavailable for one reason of another (network outage, maintenance, overload etc.). t_on_negative() looks like a pretty suitable feature for the job modulo that we need to add some scheme for distinguishing real failures, such as "number is busy", from transient ones.
The problem here is that b2bua is unable to do prefix-based routing, while we can't put b2bua between the UA and PROXY because for accounting reasons we should be able to get from b2bua IP number of the gateway the call was forwarded to. Therefore, we do gateway selection based on prefix in ser (using rewritehostport) and then just forward request to the b2bua using t_relay_to(). To catch failures and perform retries we use t_on_negative() and number of reply_route[] blocks and it is where the problem lies - after appending a new branch ser forwards the request to the host:port specified in the uri directly, but not through the b2bua.
Attached patch adds a new variable sticky_relay_to, which if set to non-zero value instructs ser to record proxy address to which transaction was originally forwarded with t_relay_to(). On failure ser forwards request to that address if another branch was appended in reply_route[].
I think that it is generally useful feature and it would be nice to see it integrated into the next release.
Thanks!
-Maxim
At 12:35 AM 2/4/2003, Maxim Sobolev wrote: [...]
t_on_negative() looks like a pretty suitable feature for the job modulo that we need to add some scheme for distinguishing real failures, such as "number is busy", from transient ones.
Agreed. Actually, it was created with such scenarios in mind.
[...]
it is where the problem lies - after appending a new branch ser forwards the request to the host:port specified in the uri directly, but not through the b2bua.
Understood.
Attached patch adds a new variable sticky_relay_to, which if set to non-zero value instructs ser to record proxy address to which transaction was originally forwarded with t_relay_to(). On failure ser forwards request to that address if another branch was appended in reply_route[].
I think that it is generally useful feature and it would be nice to see it integrated into the next release.
I'm too coffeinized right now to review the patch thoroughly -- but would not it be just simpler to _always_ keep forwarding to original destination if t_relay_to was used and to uri if t_relay was used? (i.e. sticky==always_true)
Whichever way we go, it deserves to be fixed.
-Jiri
On Tue, Feb 04, 2003 at 01:06:25AM +0100, Jiri Kuthan wrote:
At 12:35 AM 2/4/2003, Maxim Sobolev wrote: [...]
t_on_negative() looks like a pretty suitable feature for the job modulo that we need to add some scheme for distinguishing real failures, such as "number is busy", from transient ones.
Agreed. Actually, it was created with such scenarios in mind.
[...]
it is where the problem lies - after appending a new branch ser forwards the request to the host:port specified in the uri directly, but not through the b2bua.
Understood.
Attached patch adds a new variable sticky_relay_to, which if set to non-zero value instructs ser to record proxy address to which transaction was originally forwarded with t_relay_to(). On failure ser forwards request to that address if another branch was appended in reply_route[].
I think that it is generally useful feature and it would be nice to see it integrated into the next release.
I'm too coffeinized right now to review the patch thoroughly -- but would not it be just simpler to _always_ keep forwarding to original destination if t_relay_to was used and to uri if t_relay was used? (i.e. sticky==always_true)
I am not sure that it will cover all cases - in some of them it might be necessary to select another destination for the request. Actually the most generic way to handle things is to extend append_branch() to take second optional argument, to be used as a proxy for that particular branch - it will cover all possible scenarios, so that you might do t_relay(), but then in reply_route[] simulate t_relay_to() behaviour and vice versa.
-Maxim
Whichever way we go, it deserves to be fixed.
-Jiri
-
Jiri Kuthan -
Maxim Sobolev