19 Sep
2006
19 Sep
'06
6:38 p.m.
Hi,
A SIP INVITE to sip.mydoamin.com with sip.mydomain.com having two A-RR's, must
be forwarded to the first IP and if that IP is unreachable then to the
second IP. How can
I achieve this?
My first problem is that I seem to not have the list of the two IP's
available to me via a
configuration key-word. So I need to hardcode the IP's in my conf file.
My second problem is I don't know how to iterate over these two IP's.
Maybe I can
use t_on_failure() and have the second IP processed in the
failure_route[]. But then
again, how can I distinguish between a timeout and a legitimate failure?
Thank you in advance,
--
Ramin
20 Sep
20 Sep
9:23 p.m.
I don't really know if it can help, but Jan Janak made a presentation
at the last FOSDEM about such redundancy problematics. It is
available at : http://www.iptel.org/jan/
I hope it helps a bit...
Antoine
Le 19 sept. 06 à 20:38, Ramin Dousti a écrit :
Hi,
A SIP INVITE to sip.mydoamin.com with sip.mydomain.com having two A-
RR's, must
be forwarded to the first IP and if that IP is unreachable then to the
second IP. How can
I achieve this?
My first problem is that I seem to not have the list of the two IP's
available to me via a
configuration key-word. So I need to hardcode the IP's in my conf
file.
My second problem is I don't know how to iterate over these two IP's.
Maybe I can
use t_on_failure() and have the second IP processed in the
failure_route[]. But then
again, how can I distinguish between a timeout and a legitimate
failure?
Thank you in advance,
--
Ramin
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
21 Sep
21 Sep
1:38 p.m.
Hi Antoine,
Unfortunately the site is unavailable (I'll keep trying).
On the same token, I need to have some kind of redundancy. Someone
on the list recommended the usage of NAPTR, SRV for that matter but
as Bogdan pointed out that mechanism does not support automatic failover
in its current state.
Let me re-iterate my question, is there any way I could implement the
failover mechanism based on the DNS A records within the configuration
file. I've been going through the documentations and been unable to spot
such a setting. Does anyone have any configuration snippet that shows how
to "try this destination first, if the destination is unreachable, then try that
destination". Please note that the failover I'm looking for is only with regards
to the IP-connectivity failure, meaning if the next hop is not there I want to
failover, and not if the transaction to the next hop fails with some legitimate
return code.
Thanks everyone for your time/help.
Ramin
On 9/20/06, Antoine Fressancourt <af.devlist(a)gmail.com> wrote:
I don't really know if it can help, but Jan Janak
made a presentation
at the last FOSDEM about such redundancy problematics. It is
available at : http://www.iptel.org/jan/
I hope it helps a bit...
Antoine
Le 19 sept. 06 à 20:38, Ramin Dousti a écrit :
--
Ramin
Hi,
A SIP INVITE to sip.mydoamin.com with sip.mydomain.com having two A-
RR's, must
be forwarded to the first IP and if that IP is unreachable then to the
second IP. How can
I achieve this?
My first problem is that I seem to not have the list of the two IP's
available to me via a
configuration key-word. So I need to hardcode the IP's in my conf
file.
My second problem is I don't know how to iterate over these two IP's.
Maybe I can
use t_on_failure() and have the second IP processed in the
failure_route[]. But then
again, how can I distinguish between a timeout and a legitimate
failure?
Thank you in advance,
--
Ramin
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1:52 p.m.
Ramin Dousti wrote:
Hi Antoine,
Unfortunately the site is unavailable (I'll keep trying).
On the same token, I need to have some kind of redundancy. Someone
on the list recommended the usage of NAPTR, SRV for that matter but
as Bogdan pointed out that mechanism does not support automatic failover
in its current state.
Let me re-iterate my question, is there any way I could implement the
failover mechanism based on the DNS A records within the configuration
file. I've been going through the documentations and been unable to spot
such a setting. Does anyone have any configuration snippet that shows how
to "try this destination first, if the destination is unreachable,
then try that
destination". Please note that the failover I'm looking for is only
with regards
to the IP-connectivity failure, meaning if the next hop is not there I
want to
failover, and not if the transaction to the next hop fails with some
legitimate
return code.
In the proxy you can check the status of the t_relay and take corrective
action based on the result. Something like "if (t_check_status("403"))
... do something... " should work. What action you take will depend upon
the desired outcome. You could send the call to voicemail, a greeting
server, a different gateway, etc.
In the phones you can use SRV records to present a weighted list of
proxy servers. The phone would register to a domain name which is a SRV
record. This record resolves into the A records for each viable proxy.
You could weight and prioritize the A records thereby giving the phones
an ordered list of servers to try.
-Steve
Thanks everyone for your time/help.
Ramin
On 9/20/06, Antoine Fressancourt <af.devlist(a)gmail.com> wrote:
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@net.isc.upenn.edu
I don't really know if it can help, but Jan
Janak made a presentation
at the last FOSDEM about such redundancy problematics. It is
available at : http://www.iptel.org/jan/
I hope it helps a bit...
Antoine
Le 19 sept. 06 à 20:38, Ramin Dousti a écrit :
Hi,
A SIP INVITE to sip.mydoamin.com with sip.mydomain.com having two A-
RR's, must
be forwarded to the first IP and if that IP is unreachable then to the
second IP. How can
I achieve this?
My first problem is that I seem to not have the list of the two IP's
available to me via a
configuration key-word. So I need to hardcode the IP's in my conf
file.
My second problem is I don't know how to iterate over these two IP's.
Maybe I can
use t_on_failure() and have the second IP processed in the
failure_route[]. But then
again, how can I distinguish between a timeout and a legitimate
failure?
Thank you in advance,
--
Ramin
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
2:33 p.m.
On 9/21/06, Steve Blair <blairs(a)isc.upenn.edu> wrote:
Hi Steve,
> In the proxy you can check the status of the t_relay and take corrective
> action based on the result. Something like "if
(t_check_status("403"))
> ... do something... " should work. What action you take will depend upon
> the desired outcome. You could send the call to voicemail, a greeting
> server, a different gateway, etc.
Yes, that's exactly what I'm looking for. But there are some problems I'm
facing, which most probably is due to my own lack of understanding about
the available knobs:
1- When t-relay() return, the proxy already send the failure notice to
the client. This is not what I want, the "corrective action" must be
transparant
to the user.
2- I have two SRV's with the same weight, I do not see any kind of round-robin.
The request goes to only one of them.
Here is the (probably faulty) config:
route {
...
rewriteport ("");
#t_on_failure("1");
xlog("L_INFO", "Got the call\n");
if (! t_relay()) {
if (t_check_status("(403|487)|(408|477)")) {
xlog("L_ERR", "initial call failed\n");
if (t_newtran()) {
xlog("L_ERR", "Let's try again\n");
t_relay();
}
}
}
...
}
Can you help?
Ramin
> In the phones you can use SRV records to present a weighted list of
> proxy servers. The phone would register to a domain name which is a SRV
> record. This record resolves into the A records for each viable proxy.
> You could weight and prioritize the A records thereby giving the phones
> an ordered list of servers to try.
> -Steve
2:55 p.m.
Ramin,
Search the archives for serialize_branches(), next_branch(), etc..
First, I think you want to do an enum lookup before the t_relay().
With any luck, the result can be serialized using serialize_branches(),
I haven't tried this, but it makes sense. Then you set t_on_failure(1) to
catch the subsequent t_relay() failure. Finally, you need to write
failure function to load the next branch (if any) with
next_branches(), set another
on failure, then t_relay().
I looked around in the archives, there are examples with serial/next
with redirect,
but I didn't see any with srv records...should work though.
-g
On 9/21/06, Ramin Dousti <dousti(a)gmail.com> wrote:
On 9/21/06, Steve Blair <blairs(a)isc.upenn.edu>
wrote:
Hi Steve,
> In the proxy you can check the status of the t_relay and take corrective
> action based on the result. Something like "if
(t_check_status("403"))
> ... do something... " should work. What action you take will depend upon
> the desired outcome. You could send the call to voicemail, a greeting
> server, a different gateway, etc.
Yes, that's exactly what I'm looking for. But there are some problems I'm
facing, which most probably is due to my own lack of understanding about
the available knobs:
1- When t-relay() return, the proxy already send the failure notice to
the client. This is not what I want, the "corrective action" must be
transparant
to the user.
2- I have two SRV's with the same weight, I do not see any kind of round-robin.
The request goes to only one of them.
Here is the (probably faulty) config:
route {
...
rewriteport ("");
#t_on_failure("1");
xlog("L_INFO", "Got the call\n");
if (! t_relay()) {
if (t_check_status("(403|487)|(408|477)")) {
xlog("L_ERR", "initial call failed\n");
if (t_newtran()) {
xlog("L_ERR", "Let's try again\n");
t_relay();
}
}
}
...
}
Can you help?
Ramin
> In the phones you can use SRV records to present a weighted list of
> proxy servers. The phone would register to a domain name which is a SRV
> record. This record resolves into the A records for each viable proxy.
> You could weight and prioritize the A records thereby giving the phones
> an ordered list of servers to try.
> -Steve
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
Greg Fausak
greg(a)thursday.com
6:42 p.m.
Greg Fausak wrote:
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@net.isc.upenn.edu
Ramin,
Search the archives for serialize_branches(), next_branch(), etc..
First, I think you want to do an enum lookup before the t_relay().
With any luck, the result can be serialized using serialize_branches(),
I haven't tried this, but it makes sense. Then you set
t_on_failure(1) to
catch the subsequent t_relay() failure. Finally, you need to write
failure function to load the next branch (if any) with
next_branches(), set another
on failure, then t_relay().
I looked around in the archives, there are examples with serial/next
with redirect,
but I didn't see any with srv records...should work though.
-g
On 9/21/06, Ramin Dousti <dousti(a)gmail.com> wrote:
Are you defining a failure route before calling t_relay? If so
comment
out the t_on_failure statement. Then from a route block try t_relay
followed by if (t_check_status...) command. Depending upon the result
you may then want to set the t_on_failure route to handle any subsequent
On 9/21/06, Steve Blair
<blairs(a)isc.upenn.edu> wrote:
Hi Steve,
Yes, that's exactly what I'm looking for. But there are some problems
I'm
facing, which most probably is due to my own lack of understanding about
the available knobs:
1- When t-relay() return, the proxy already send the failure notice to
the client. This is not what I want, the "corrective action" must be
transparant
to the user.
In the proxy you can check the status of the
t_relay and take
corrective
action based on the result. Something like
"if (t_check_status("403"))
... do something... " should work. What action you take will depend
upon
> the desired outcome. You could send the call to voicemail, a greeting
> server, a different gateway, etc.
2xx status conditions.
>
> 2- I have two SRV's with the same weight, I do not see any kind of
> round-robin.
> The request goes to only one of them.
>
I did not mean to suggest that SRV would enable round robin. Sorry about
that. I use SRV records in the way I described to provide failure over
on initial invite. It works well but it will not handle round robin.
You may want to try a redirect. Have the phone register to a server
which can replicate the registration to other servers. Then when the
primary receives the initial invite reply with a redirect statement to
instruct the phone to try another proxy. Replication should eliminate
any registration questions. You will need to develop a weighting
algorithm which can be shared across all proxy servers. I think a 305
Use Proxy response should be sufficient to handle the redirect.
-Steve
Here is the
(probably faulty) config:
route {
...
rewriteport ("");
#t_on_failure("1");
xlog("L_INFO", "Got the call\n");
if (! t_relay()) {
if (t_check_status("(403|487)|(408|477)")) {
xlog("L_ERR", "initial call failed\n");
if (t_newtran()) {
xlog("L_ERR", "Let's try again\n");
t_relay();
}
}
}
...
}
Can you help?
Ramin
In the phones you can use SRV records to present
a weighted list of
proxy servers. The phone would register to a domain name which is a
SRV
record. This record resolves into the A records
for each viable proxy.
You could weight and prioritize the A records thereby giving the
phones
an ordered list of servers to try.
-Steve
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6508
days inactive
6510
days old
6 comments
4 participants
participants (4)
-
Antoine Fressancourt -
Greg Fausak -
Ramin Dousti -
Steve Blair