Hi I'm trying to get something to work that I thought should work out of the box, but when implemented didn't work the way I thought it would... Please comment.
I'm using OpenSER as a core SIP proxy, among other things to connect to a POTS network via two independent Cisco PGW2200 SS7 GW. These gateways have fully DNS resolvable SIP domains (rfc 3263, NAPTR, SRV and A records). NAPTR (udp only) => SRV (udp only) => 2x A records (one for each redundant GW). Calls directed to POTS nicely load shares between the two A records. So far so good.
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
I would love some best practice implementation clues regarding OpenSER and multiple GW fail over, if anyone of you have such knowledge or experience.
Best regards, /Staffan
--- Staffan Kerker, Saab Communication Ljungadalsgatan 2, 35180 Växjö, Sweden
p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com w. http://www.saabgroup.com
openser does not support DNS based failover (nor NAPTR nor SRV nur multiple A records).
with openser you have to use the dispatcher module for this. you might also try ser CVS which has DNS based failover - but I have not tried it yet.
regards klaus
Kerker Staffan wrote:
Hi I'm trying to get something to work that I thought should work out of the box, but when implemented didn't work the way I thought it would... Please comment.
I'm using OpenSER as a core SIP proxy, among other things to connect to a POTS network via two independent Cisco PGW2200 SS7 GW. These gateways have fully DNS resolvable SIP domains (rfc 3263, NAPTR, SRV and A records). NAPTR (udp only) => SRV (udp only) => 2x A records (one for each redundant GW). Calls directed to POTS nicely load shares between the two A records. So far so good.
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
I would love some best practice implementation clues regarding OpenSER and multiple GW fail over, if anyone of you have such knowledge or experience.
Best regards, /Staffan
Staffan Kerker, Saab Communication Ljungadalsgatan 2, 35180 Växjö, Sweden
p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com w. http://www.saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Staffan,
Kerker Staffan wrote: ...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should do RFC 3263 based fail-over. But as you can imagine this is pretty complex to implement and that's why openser does not support it yet, it is listed on the development roadmap. The newest release of SER does support DNS failover.
But it is possible to implement failover with OpenSER, you just have to configure it manually on the proxy. And you have to adjust the SIP session timers of the tm module to achieve fast failovers.
Here is an overview of how I implemented failover with OpenSER (there are other ways to do that):
I use the dispatcher module with a non-random dispatcher algorithm to get deterministic failover.
dispatcher config file could look like:
1 sip:gw-1.example.com 1 sip:gw-2.example.com
In the openser config file, I call the ds_select_domain() function just before t_relay. And in the failure_route I then use ds_next_domain() to select the next target from the dispatcher config file.
In order to get short failover times one has to adjust fr_timer for INVITE transactions. For INVITE transactions, fr_timer is the max time openser waits for a reply from the downstream SIP entity. As soon as openser receives such a reply, it will use fr_inv_timer as the final response timer. Per default fr_timer is 30 seconds so openser would wait about 30 seconds before trying the next target.
An openser config that does failover between gw-1.example.com and gw-2.example.com for gw.example could look like:
modparam("tm", "fr_timer_avp", "i:24") # AVP to set fr_timer modparam("avpops","avp_aliases","fr_timer=i:24")
# failover support --> store dests in avp value modparam("dispatcher", "flags", 2)
route[0] { ... if (is_method("INVITE") && uri=~"sip:.*@gw.example.com") {
# replace domain part with first dispatcher target of group 1 ds_select_domain("1", "9"); # alg 9 --> use first, second, etc
# set fr_timer to 3 seconds (3 seconds for failover) avp_write("i:3", "$avp(fr_timer)");
t_on_failure("1"); t_relay(); exit; } ... }
failure_route[1] { ... # status is 408 if openser session timer fires if (t_check_status("408")) { # replace domain part with next dispatcher target if (ds_next_domain()) { t_relay(); exit; } } ... }
- Christian
I would love some best practice implementation clues regarding OpenSER and multiple GW fail over, if anyone of you have such knowledge or experience.
Best regards, /Staffan
Staffan Kerker, Saab Communication Ljungadalsgatan 2, 35180 Växjö, Sweden
p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com w. http://www.saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
We are currently working on bit of a hackish way to honor SRV records. Please poke holes as appropriate.
We will run a separate process that looks up a SRV record and then generates local A records based on the results. Using the dispatcher module in a similar fashion to what Christian describes below we then dispatch to the pre agreed upon domain, resolved locally. When the SRV results change we resolve the pre agreed domain to reflect the change.
Example:
SRV returns 2 A records
server1.carrier.com priority 1 resolves to 4.5.6.7 server2.carrier.com priority 2 resolves to 5.6.7.8
We then build a fake local domain to match server1.carrier.fake 4.5.6.7 server2.carrier.fake 5.6.7.8
The dispatcher list looks like this:
1 server1.carrier.fake 1 server2.carrier.fake
Now openser will always pick the first server and fail to the second server using the mechanism Christian describes.
At some predefined interval our external process will check the SRV record of the carrier. Let's say it has now changed where server1 is priority 2 and server2 is priority 1 ( reversed from before). The external process updates our local DNS to resolve server1.carrier.fake to 5.6.7.8 and server2.carrier.com to 4.5.6.7
In this manner using an external process and local DNS ( in our case we use DJBs tinydns ) we are honoring dynamic priority changing in SRV records with openser.
This is still a work in progress. Will update once we have it up and running.
Couple of caveats, we assume the number of records returned from the SRV lookup will be consistent, since we have to build the same number of fake domains. Also we assume we are dealing with priority routing not round robin, though round robin would work, only the dispatcher algorithm would need to change.
T.R.
On 1/11/07 11:36 AM, "Christian Schlatter" cs@unc.edu wrote:
Staffan,
Kerker Staffan wrote: ...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should do RFC 3263 based fail-over. But as you can imagine this is pretty complex to implement and that's why openser does not support it yet, it is listed on the development roadmap. The newest release of SER does support DNS failover.
But it is possible to implement failover with OpenSER, you just have to configure it manually on the proxy. And you have to adjust the SIP session timers of the tm module to achieve fast failovers.
Here is an overview of how I implemented failover with OpenSER (there are other ways to do that):
I use the dispatcher module with a non-random dispatcher algorithm to get deterministic failover.
dispatcher config file could look like:
1 sip:gw-1.example.com 1 sip:gw-2.example.com
In the openser config file, I call the ds_select_domain() function just before t_relay. And in the failure_route I then use ds_next_domain() to select the next target from the dispatcher config file.
In order to get short failover times one has to adjust fr_timer for INVITE transactions. For INVITE transactions, fr_timer is the max time openser waits for a reply from the downstream SIP entity. As soon as openser receives such a reply, it will use fr_inv_timer as the final response timer. Per default fr_timer is 30 seconds so openser would wait about 30 seconds before trying the next target.
An openser config that does failover between gw-1.example.com and gw-2.example.com for gw.example could look like:
modparam("tm", "fr_timer_avp", "i:24") # AVP to set fr_timer modparam("avpops","avp_aliases","fr_timer=i:24")
# failover support --> store dests in avp value modparam("dispatcher", "flags", 2)
route[0] { ... if (is_method("INVITE") && uri=~"sip:.*@gw.example.com") {
# replace domain part with first dispatcher target of group 1 ds_select_domain("1", "9"); # alg 9 --> use first, second, etc # set fr_timer to 3 seconds (3 seconds for failover) avp_write("i:3", "$avp(fr_timer)"); t_on_failure("1"); t_relay(); exit;} ... }
failure_route[1] { ... # status is 408 if openser session timer fires if (t_check_status("408")) { # replace domain part with next dispatcher target if (ds_next_domain()) { t_relay(); exit; } } ... }
- Christian
I would love some best practice implementation clues regarding OpenSER and multiple GW fail over, if anyone of you have such knowledge or experience.
Best regards, /Staffan
Staffan Kerker, Saab Communication Ljungadalsgatan 2, 35180 Växjö, Sweden
p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com w. http://www.saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Interesting solution, maybe using an undefined algorithm in dispatcher functions helps, since it will use the first entry, and if failover is turned on, the next addresses will be loaded in AVP list -- no need for choosing the round robin. Adding a new id for an algorithm of selecting the destinations in the order they are in the list sounds like a good idea.
On the other hand, the plan is to have th DNS failover available in the next major release, 1.2.0.
Cheers, Daniel
On 01/12/07 18:46, T.R. Missner wrote:
We are currently working on bit of a hackish way to honor SRV records. Please poke holes as appropriate.
We will run a separate process that looks up a SRV record and then generates local A records based on the results. Using the dispatcher module in a similar fashion to what Christian describes below we then dispatch to the pre agreed upon domain, resolved locally. When the SRV results change we resolve the pre agreed domain to reflect the change.
Example:
SRV returns 2 A records
server1.carrier.com priority 1 resolves to 4.5.6.7 server2.carrier.com priority 2 resolves to 5.6.7.8
We then build a fake local domain to match server1.carrier.fake 4.5.6.7 server2.carrier.fake 5.6.7.8
The dispatcher list looks like this:
1 server1.carrier.fake 1 server2.carrier.fake
Now openser will always pick the first server and fail to the second server using the mechanism Christian describes.
At some predefined interval our external process will check the SRV record of the carrier. Let's say it has now changed where server1 is priority 2 and server2 is priority 1 ( reversed from before). The external process updates our local DNS to resolve server1.carrier.fake to 5.6.7.8 and server2.carrier.com to 4.5.6.7
In this manner using an external process and local DNS ( in our case we use DJBs tinydns ) we are honoring dynamic priority changing in SRV records with openser.
This is still a work in progress. Will update once we have it up and running.
Couple of caveats, we assume the number of records returned from the SRV lookup will be consistent, since we have to build the same number of fake domains. Also we assume we are dealing with priority routing not round robin, though round robin would work, only the dispatcher algorithm would need to change.
T.R.
On 1/11/07 11:36 AM, "Christian Schlatter" cs@unc.edu wrote:
Staffan,
Kerker Staffan wrote: ...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should do RFC 3263 based fail-over. But as you can imagine this is pretty complex to implement and that's why openser does not support it yet, it is listed on the development roadmap. The newest release of SER does support DNS failover.
But it is possible to implement failover with OpenSER, you just have to configure it manually on the proxy. And you have to adjust the SIP session timers of the tm module to achieve fast failovers.
Here is an overview of how I implemented failover with OpenSER (there are other ways to do that):
I use the dispatcher module with a non-random dispatcher algorithm to get deterministic failover.
dispatcher config file could look like:
1 sip:gw-1.example.com 1 sip:gw-2.example.com
In the openser config file, I call the ds_select_domain() function just before t_relay. And in the failure_route I then use ds_next_domain() to select the next target from the dispatcher config file.
In order to get short failover times one has to adjust fr_timer for INVITE transactions. For INVITE transactions, fr_timer is the max time openser waits for a reply from the downstream SIP entity. As soon as openser receives such a reply, it will use fr_inv_timer as the final response timer. Per default fr_timer is 30 seconds so openser would wait about 30 seconds before trying the next target.
An openser config that does failover between gw-1.example.com and gw-2.example.com for gw.example could look like:
modparam("tm", "fr_timer_avp", "i:24") # AVP to set fr_timer modparam("avpops","avp_aliases","fr_timer=i:24")
# failover support --> store dests in avp value modparam("dispatcher", "flags", 2)
route[0] { ... if (is_method("INVITE") && uri=~"sip:.*@gw.example.com") {
# replace domain part with first dispatcher target of group 1 ds_select_domain("1", "9"); # alg 9 --> use first, second, etc # set fr_timer to 3 seconds (3 seconds for failover) avp_write("i:3", "$avp(fr_timer)"); t_on_failure("1"); t_relay(); exit;} ... }
failure_route[1] { ... # status is 408 if openser session timer fires if (t_check_status("408")) { # replace domain part with next dispatcher target if (ds_next_domain()) { t_relay(); exit; } } ... }
- Christian
I would love some best practice implementation clues regarding OpenSER and multiple GW fail over, if anyone of you have such knowledge or experience.
Best regards, /Staffan
Staffan Kerker, Saab Communication Ljungadalsgatan 2, 35180 Växjö, Sweden
p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com w. http://www.saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla wrote:
Interesting solution, maybe using an undefined algorithm in dispatcher functions helps, since it will use the first entry, and if failover is turned on, the next addresses will be loaded in AVP list -- no need for choosing the round robin. Adding a new id for an algorithm of selecting the destinations in the order they are in the list sounds like a good idea.
On the other hand, the plan is to have th DNS failover available in the next major release, 1.2.0.
Hi Daniel!
It would be cool to cache broken destinations too :-)
regards klaus
Cheers, Daniel
On 01/12/07 18:46, T.R. Missner wrote:
We are currently working on bit of a hackish way to honor SRV records. Please poke holes as appropriate.
We will run a separate process that looks up a SRV record and then generates local A records based on the results. Using the dispatcher module in a similar fashion to what Christian describes below we then dispatch to the pre agreed upon domain, resolved locally. When the SRV results change we resolve the pre agreed domain to reflect the change.
Example:
SRV returns 2 A records
server1.carrier.com priority 1 resolves to 4.5.6.7 server2.carrier.com priority 2 resolves to 5.6.7.8
We then build a fake local domain to match server1.carrier.fake 4.5.6.7 server2.carrier.fake 5.6.7.8
The dispatcher list looks like this:
1 server1.carrier.fake 1 server2.carrier.fake
Now openser will always pick the first server and fail to the second server using the mechanism Christian describes.
At some predefined interval our external process will check the SRV record of the carrier. Let's say it has now changed where server1 is priority 2 and server2 is priority 1 ( reversed from before). The external process updates our local DNS to resolve server1.carrier.fake to 5.6.7.8 and server2.carrier.com to 4.5.6.7
In this manner using an external process and local DNS ( in our case we use DJBs tinydns ) we are honoring dynamic priority changing in SRV records with openser.
This is still a work in progress. Will update once we have it up and running.
Couple of caveats, we assume the number of records returned from the SRV lookup will be consistent, since we have to build the same number of fake domains. Also we assume we are dealing with priority routing not round robin, though round robin would work, only the dispatcher algorithm would need to change.
T.R.
On 1/11/07 11:36 AM, "Christian Schlatter" cs@unc.edu wrote:
Staffan,
Kerker Staffan wrote: ...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should do RFC 3263 based fail-over. But as you can imagine this is pretty complex to implement and that's why openser does not support it yet, it is listed on the development roadmap. The newest release of SER does support DNS failover.
But it is possible to implement failover with OpenSER, you just have to configure it manually on the proxy. And you have to adjust the SIP session timers of the tm module to achieve fast failovers.
Here is an overview of how I implemented failover with OpenSER (there are other ways to do that):
I use the dispatcher module with a non-random dispatcher algorithm to get deterministic failover.
dispatcher config file could look like:
1 sip:gw-1.example.com 1 sip:gw-2.example.com
In the openser config file, I call the ds_select_domain() function just before t_relay. And in the failure_route I then use ds_next_domain() to select the next target from the dispatcher config file.
In order to get short failover times one has to adjust fr_timer for INVITE transactions. For INVITE transactions, fr_timer is the max time openser waits for a reply from the downstream SIP entity. As soon as openser receives such a reply, it will use fr_inv_timer as the final response timer. Per default fr_timer is 30 seconds so openser would wait about 30 seconds before trying the next target.
An openser config that does failover between gw-1.example.com and gw-2.example.com for gw.example could look like:
modparam("tm", "fr_timer_avp", "i:24") # AVP to set fr_timer modparam("avpops","avp_aliases","fr_timer=i:24")
# failover support --> store dests in avp value modparam("dispatcher", "flags", 2)
route[0] { ... if (is_method("INVITE") && uri=~"sip:.*@gw.example.com") {
# replace domain part with first dispatcher target of group 1 ds_select_domain("1", "9"); # alg 9 --> use first, second, etc # set fr_timer to 3 seconds (3 seconds for failover) avp_write("i:3", "$avp(fr_timer)"); t_on_failure("1"); t_relay(); exit;} ... }
failure_route[1] { ... # status is 408 if openser session timer fires if (t_check_status("408")) { # replace domain part with next dispatcher target if (ds_next_domain()) { t_relay(); exit; } } ... }
- Christian
I would love some best practice implementation clues regarding OpenSER and multiple GW fail over, if anyone of you have such knowledge or experience.
Best regards, /Staffan
Staffan Kerker, Saab Communication Ljungadalsgatan 2, 35180 Växjö, Sweden
p. +46 470 42185 c. +46 705 391365 m. staffan.kerker@saabgroup.com w. http://www.saabgroup.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote: ...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should do RFC 3263 based fail-over. But as you can imagine this is pretty complex to implement and that's why openser does not support it yet, it is listed on the development roadmap. The newest release of SER does support DNS failover.
Greg,
This is a ref to SER. Apparently this functionality has been added to the new pre-release version. I did find some talk about it in the release notes. I couldn¹t find any specific documentation. Admittedly I don¹t understand the layout of SER¹s site very well as I haven¹t spent much time there.
-- TR
On 1/15/07 8:33 PM, "Greg Fausak" lgfausak@gmail.com wrote:
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote:
...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does
not
try the second A record address if the first doesn't answer. How can I solve
this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR
=> SRV
resolving? Or will OpenSER continue to resend all SIP INVITES until timers
fire? Would
it help if the proxy recieved an ICMP port/destination unreachable from the
network? Is
there anyway to get around this? In the other direction, from POTS to sip,
the PGW2200
nicely switches over to the second of my two OpenSER servers if I shut one of
them down. These servers have the same DNS entries (but for another SIP domain, NAPTR =>
SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should
do RFC 3263 based fail-over. But as you can imagine this is pretty
complex to implement and that's why openser does not support it yet, it
is listed on the development roadmap. The newest release of SER does
support DNS failover.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
indeed, the stuff is not well linked, we are working on it. Here you go. http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/doc/dns.txt?rev=HEA...
-jiri
At 02:46 16/01/2007, T.R. Missner wrote:
Greg,
This is a ref to SER. Apparently this functionality has been added to the new pre-release version. I did find some talk about it in the release notes. I couldn�t find any specific documentation. Admittedly I don�t understand the layout of SER�s site very well as I haven�t spent much time there.
-- TR
On 1/15/07 8:33 PM, "Greg Fausak" lgfausak@gmail.com wrote:
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote:
...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does
not
try the second A record address if the first doesn't answer. How can I solve
this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR
=> SRV
resolving? Or will OpenSER continue to resend all SIP INVITES until timers
fire? Would
it help if the proxy recieved an ICMP port/destination unreachable from the
network? Is
there anyway to get around this? In the other direction, from POTS to sip,
the PGW2200
nicely switches over to the second of my two OpenSER servers if I shut one of
them down. These servers have the same DNS entries (but for another SIP domain, NAPTR =>
SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should
do RFC 3263 based fail-over. But as you can imagine this is pretty
complex to implement and that's why openser does not support it yet, it
is listed on the development roadmap. The newest release of SER does
support DNS failover.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri,
Thanks for the pointer! I think I'll have to give this a look. We are having specific problems with the DNS resolver on failover (when one DNS resolver is not reachable, the next is queried, and openser is not acting predictably when this happens). It is as if the tm module is not properly threaded. Like when one thread gets stuck waiting for a response from DNS resolver, another thread picks up a retry SIP message and doesn't know about the retry in process!
We see the bad resolver behavior when 2 resolvers are listed in /etc/ resolv.conf, and we turn off the first one.
The DNS failover is also interesting. I think failover applies to A records and SRV records (not NAPTR records).
-g
On Jan 16, 2007, at 7:12 AM, Jiri Kuthan wrote:
indeed, the stuff is not well linked, we are working on it. Here you go. http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/doc/ dns.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
-jiri
At 02:46 16/01/2007, T.R. Missner wrote:
Greg,
This is a ref to SER. Apparently this functionality has been added to the new pre-release version. I did find some talk about it in the release notes. I couldn’t find any specific documentation. Admittedly I don’t understand the layout of SER’s site very well as I haven’t spent much time there.
-- TR
On 1/15/07 8:33 PM, "Greg Fausak" lgfausak@gmail.com wrote:
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote:
...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does
not
try the second A record address if the first doesn't answer. How can I solve
this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR
=> SRV
resolving? Or will OpenSER continue to resend all SIP INVITES until timers
fire? Would
it help if the proxy recieved an ICMP port/destination unreachable from the
network? Is
there anyway to get around this? In the other direction, from POTS to sip,
the PGW2200
nicely switches over to the second of my two OpenSER servers if I shut one of
them down. These servers have the same DNS entries (but for another SIP domain, NAPTR =>
SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should
do RFC 3263 based fail-over. But as you can imagine this is pretty
complex to implement and that's why openser does not support it yet, it
is listed on the development roadmap. The newest release of SER does
support DNS failover.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp:// openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
At 14:59 16/01/2007, Greg Fausak wrote:
Jiri,
Thanks for the pointer! I think I'll have to give this a look.
Hi Greg,
with pleasure. Just keep in mind that having robustness in there takes couple of other steps. Particularly IP blacklisting to avoid attempts to send to the DNS-conveyed destinations, which are unavailable and ...
We are having specific problems with the DNS resolver on failover (when one DNS resolver is not reachable, the next is queried, and openser is not acting predictably when this happens). It is as if the tm module is not properly threaded. Like when one thread gets stuck waiting for a response from DNS resolver, another thread picks up a retry SIP message and doesn't know about the retry in process!
... building the ser script in a way that retransmissions are absorbed (kind of having "shock absorber" in place)
-jiri
We see the bad resolver behavior when 2 resolvers are listed in /etc/ resolv.conf, and we turn off the first one.
The DNS failover is also interesting. I think failover applies to A records and SRV records (not NAPTR records).
-g
On Jan 16, 2007, at 7:12 AM, Jiri Kuthan wrote:
indeed, the stuff is not well linked, we are working on it. Here you go. http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/doc/ dns.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
-jiri
At 02:46 16/01/2007, T.R. Missner wrote:
Greg,
This is a ref to SER. Apparently this functionality has been added to the new pre-release version. I did find some talk about it in the release notes. I couldn�t find any specific documentation. Admittedly I don�t understand the layout of SER�s site very well as I haven�t spent much time there.
-- TR
On 1/15/07 8:33 PM, "Greg Fausak" lgfausak@gmail.com wrote:
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote:
...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does
not
try the second A record address if the first doesn't answer. How can I solve
this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR
=> SRV
resolving? Or will OpenSER continue to resend all SIP INVITES until timers
fire? Would
it help if the proxy recieved an ICMP port/destination unreachable from the
network? Is
there anyway to get around this? In the other direction, from POTS to sip,
the PGW2200
nicely switches over to the second of my two OpenSER servers if I shut one of
them down. These servers have the same DNS entries (but for another SIP domain, NAPTR =>
SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should
do RFC 3263 based fail-over. But as you can imagine this is pretty
complex to implement and that's why openser does not support it yet, it
is listed on the development roadmap. The newest release of SER does
support DNS failover.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp:// openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/
On Jan 16, 2007, at 8:17 AM, Jiri Kuthan wrote:
At 14:59 16/01/2007, Greg Fausak wrote:
Jiri,
Thanks for the pointer! I think I'll have to give this a look.
Hi Greg,
with pleasure. Just keep in mind that having robustness in there takes couple of other steps. Particularly IP blacklisting to avoid attempts to send to the DNS-conveyed destinations, which are unavailable and ...
We are having specific problems with the DNS resolver on failover (when one DNS resolver is not reachable, the next is queried, and openser is not acting predictably when this happens). It is as if the tm module is not properly threaded. Like when one thread gets stuck waiting for a response from DNS resolver, another thread picks up a retry SIP message and doesn't know about the retry in process!
... building the ser script in a way that retransmissions are absorbed (kind of having "shock absorber" in place)
Retransmissions are good (most of the time). Somehow the ser script would need to know that there is another thread tending to a DNS lookup. How does my script know if a message is original, or a retransmission anyway?
It seems to me that the tm module should be reaping the retransmits.
-g
-jiri
We see the bad resolver behavior when 2 resolvers are listed in / etc/ resolv.conf, and we turn off the first one.
The DNS failover is also interesting. I think failover applies to A records and SRV records (not NAPTR records).
-g
On Jan 16, 2007, at 7:12 AM, Jiri Kuthan wrote:
indeed, the stuff is not well linked, we are working on it. Here you go. http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/doc/ dns.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
-jiri
At 02:46 16/01/2007, T.R. Missner wrote:
Greg,
This is a ref to SER. Apparently this functionality has been added to the new pre-release version. I did find some talk about it in the release notes. I couldn’t find any specific documentation. Admittedly I don’t understand the layout of SER’s site very well as I haven’t spent much time there.
-- TR
On 1/15/07 8:33 PM, "Greg Fausak" lgfausak@gmail.com wrote:
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote:
...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does
not
try the second A record address if the first doesn't answer. How can I solve
this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR
=> SRV
resolving? Or will OpenSER continue to resend all SIP INVITES until timers
fire? Would
it help if the proxy recieved an ICMP port/destination unreachable from the
network? Is
there anyway to get around this? In the other direction, from POTS to sip,
the PGW2200
nicely switches over to the second of my two OpenSER servers if I shut one of
them down. These servers have the same DNS entries (but for another SIP domain, NAPTR =>
SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should
do RFC 3263 based fail-over. But as you can imagine this is pretty
complex to implement and that's why openser does not support it yet, it
is listed on the development roadmap. The newest release of SER does
support DNS failover.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp:// openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/
Greg Fausak wrote:
On Jan 16, 2007, at 8:17 AM, Jiri Kuthan wrote:
At 14:59 16/01/2007, Greg Fausak wrote:
Jiri,
Thanks for the pointer! I think I'll have to give this a look.
Hi Greg,
with pleasure. Just keep in mind that having robustness in there takes couple of other steps. Particularly IP blacklisting to avoid attempts to send to the DNS-conveyed destinations, which are unavailable and ...
We are having specific problems with the DNS resolver on failover (when one DNS resolver is not reachable, the next is queried, and openser is not acting predictably when this happens). It is as if the tm module is not properly threaded. Like when one thread gets stuck waiting for a response from DNS resolver, another thread picks up a retry SIP message and doesn't know about the retry in process!
... building the ser script in a way that retransmissions are absorbed (kind of having "shock absorber" in place)
Retransmissions are good (most of the time). Somehow the ser script would need to know that there is another thread tending to a DNS lookup. How does my script know if a message is original, or a retransmission anyway?
It seems to me that the tm module should be reaping the retransmits.
At first the proxy should reply 100 trying to stop retransmissions.
Further, the retransmissions should be absorbed by tm - if not then we should analyze it.
regards klaus
-g
-jiri
We see the bad resolver behavior when 2 resolvers are listed in /etc/ resolv.conf, and we turn off the first one.
The DNS failover is also interesting. I think failover applies to A records and SRV records (not NAPTR records).
-g
On Jan 16, 2007, at 7:12 AM, Jiri Kuthan wrote:
indeed, the stuff is not well linked, we are working on it. Here you go. http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/doc/ dns.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
-jiri
At 02:46 16/01/2007, T.R. Missner wrote:
Greg,
This is a ref to SER. Apparently this functionality has been added to the new pre-release version. I did find some talk about it in the release notes. I couldn’t find any specific documentation. Admittedly I don’t understand the layout of SER’s site very well as I haven’t spent much time there.
-- TR
On 1/15/07 8:33 PM, "Greg Fausak" lgfausak@gmail.com wrote:
In the text below I quote Kerker 'SER does support DNS failover.'. Is this ser or openser? Where can I read more about this?
-g
On Jan 15, 2007, at 10:40 AM, Klaus Darilion wrote:
Staffan,
Kerker Staffan wrote:
...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does
not
try the second A record address if the first doesn't answer. How can I solve
this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR
=> SRV
resolving? Or will OpenSER continue to resend all SIP INVITES until timers
fire? Would
it help if the proxy recieved an ICMP port/destination unreachable from the
network? Is
there anyway to get around this? In the other direction, from POTS to sip,
the PGW2200
nicely switches over to the second of my two OpenSER servers if I shut one of
them down. These servers have the same DNS entries (but for another SIP domain, NAPTR =>
SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should
do RFC 3263 based fail-over. But as you can imagine this is pretty
complex to implement and that's why openser does not support it yet, it
is listed on the development roadmap. The newest release of SER does
support DNS failover.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/usershttp:// openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
Klaus Darilion wrote:
Retransmissions are good (most of the time). Somehow the ser script would need to know that there is another thread tending to a DNS lookup. How does my script know if a message is original, or a retransmission anyway?
It seems to me that the tm module should be reaping the retransmits.
At first the proxy should reply 100 trying to stop retransmissions.
this is very and elegant to do with the new flags in t_reply(). You can statelessly send a 100 and configure t_relay() not to do it again. See: http://www.openser.org/docs/modules/1.2.x/tm.html#AEN342
letting t_relay() to auto generate the 100 is in most of the case futile, as it is too late.
Further, the retransmissions should be absorbed by tm - if not then we should analyze it.
the TM functions do that, but again, in most of the case it, as the relaying is done at the end of processing, it can be a wast of computation and time - just to apply all changes and perform ops to figure out at the end that the request was a retransmission. So, you can use the t_check_trans() function from the beginning: http://www.openser.org/docs/modules/1.2.x/tm.html#AEN482
the great part is that the function does not affect the further processing and has no computation penalties.
regards, bogdan
At 16:46 16/01/2007, Bogdan-Andrei Iancu wrote:
the TM functions do that, but again, in most of the case it, as the relaying is done at the end of processing, it can be a wast of computation and time - just to apply all changes and perform ops to figure out at the end that the request was a retransmission.
That's a trade-off but I guess that for most uses the threat caused by blocked processes is more compelling that the penalty caused by extra transaction lookup.
So, you can use the t_check_trans() function from the beginning: http://www.openser.org/docs/modules/1.2.x/tm.html#AEN482
Is it safe against race conditions? (I mean after the function was left, can its result be obsoleted by another process running in parallel?)
-jiri
the great part is that the function does not affect the further processing and has no computation penalties.
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
At 15:38 16/01/2007, Greg Fausak wrote:
Retransmissions are good (most of the time). Somehow the ser script would need to know that there is another thread tending to a DNS lookup. How does my script know if a message is original, or a retransmission anyway?
That's the think ... expensive request processing must be wrapped in transaction processing in your script, otherwise every single retranmission will trigger it all over times again.
It seems to me that the tm module should be reaping the retransmits.
Yes, the it is responsibility of tm code and properly designed script (and properly set up DNS and properly set up blacklisting).
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
At 17:36 11/01/2007, Christian Schlatter wrote:
Staffan,
Kerker Staffan wrote: ...
Now, if I disable one of the Gateways, I hang every second call. OpenSER does not try the second A record address if the first doesn't answer. How can I solve this? Shouldn't OpenSER fail over to the second A record listed in the NAPTR => SRV resolving? Or will OpenSER continue to resend all SIP INVITES until timers fire? Would it help if the proxy recieved an ICMP port/destination unreachable from the network? Is there anyway to get around this? In the other direction, from POTS to sip, the PGW2200 nicely switches over to the second of my two OpenSER servers if I shut one of them down. These servers have the same DNS entries (but for another SIP domain, NAPTR => SRV => 2x A record).
Yes, OpenSER or for that matter every transaction stateful proxy should do RFC 3263 based fail-over. But as you can imagine this is pretty complex to implement and that's why openser does not support it yet, it is listed on the development roadmap. The newest release of SER does support DNS failover.
Indeed. SER does so. See the doc at http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/doc/dns.txt?rev=HEA... -jiri
-- Jiri Kuthan http://iptel.org/~jiri/
-
Bogdan-Andrei Iancu -
Christian Schlatter -
Daniel-Constantin Mierla -
Greg Fausak -
Jiri Kuthan -
Kerker Staffan -
Klaus Darilion -
T.R. Missner