Re: [asterisk-users] Realtime SIP, multiple AX servers question
On Jan 4, 2011, at 12:26 PM, Tilghman Lesher wrote: It wasn't designed to do this. While you can have the same sippeers table for multiple servers, you really should have a separate sipregs table for each backend server. The reason why is that some mappings depend implicitly on the host to which it was registered. For example, if a phone is behind a NAT, then the external port is dependent upon the same host responding. If a different host tries to communicate to that external port, some NAT devices will not route the packet properly. This is especially true for SIP over TCP, but it's also true for UDP packets. (Routing packets back through a NAT without verifying the sending IP is a security risk.) Probably more appropriate for your case is to use DUNDi to coordinate your machines as to which server presents holds the registration for any specific phone. We have one table which is serving both purposes (peers and reg). When we want to route a call to an ATA, we first look up that ATA's regserver in that table, and then construct a SIP URI based upon that regserver address. In that way, we route the call through the server to which the ATA is currently registered. So I guess we're covered already in the scenario you describe. It seems like not a great design to have to have a private sipregs table for every server in our pool, especially given that the pool will grow (or maybe shrink) over time. Is that really the recommended design? I haven't seen any articles describing that setup for RealTime in a multi-server environment. Thank you, Bryan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime SIP, multiple AX servers question
On 01/05/2011 09:39 AM, Bryan Field-Elliot wrote: We have one table which is serving both purposes (peers and reg). When we want to route a call to an ATA, we first look up that ATA's regserver in that table, and then construct a SIP URI based upon that regserver address. In that way, we route the call through the server to which the ATA is currently registered. So I guess we're covered already in the scenario you describe. It seems like not a great design to have to have a private sipregs table for every server in our pool, especially given that the pool will grow (or maybe shrink) over time. Is that really the recommended design? I haven't seen any articles describing that setup for RealTime in a multi-server environment. Asterisk Realtime was designed to make dynamic configuration possible, and then later extended to provide a way to store *some* data outside of astdb. It was never intended to provide a failover or data-sharing mechanism, and none of the code attempts to take that into account. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kflem...@digium.com Check us out at www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime SIP, multiple AX servers question
On Wednesday 05 January 2011 09:39:00 Bryan Field-Elliot wrote: On Jan 4, 2011, at 12:26 PM, Tilghman Lesher wrote: It wasn't designed to do this. While you can have the same sippeers table for multiple servers, you really should have a separate sipregs table for each backend server. The reason why is that some mappings depend implicitly on the host to which it was registered. For example, if a phone is behind a NAT, then the external port is dependent upon the same host responding. If a different host tries to communicate to that external port, some NAT devices will not route the packet properly. This is especially true for SIP over TCP, but it's also true for UDP packets. (Routing packets back through a NAT without verifying the sending IP is a security risk.) Probably more appropriate for your case is to use DUNDi to coordinate your machines as to which server presents holds the registration for any specific phone. We have one table which is serving both purposes (peers and reg). When we want to route a call to an ATA, we first look up that ATA's regserver in that table, and then construct a SIP URI based upon that regserver address. In that way, we route the call through the server to which the ATA is currently registered. So I guess we're covered already in the scenario you describe. It seems like not a great design to have to have a private sipregs table for every server in our pool, especially given that the pool will grow (or maybe shrink) over time. Is that really the recommended design? I haven't seen any articles describing that setup for RealTime in a multi-server environment. Sorry, but a private table for sipregs for each server was exactly what it designed for, in order to separate out values which change per-server from general configuration (same for every server). While I understand that you're presently using a separate lookup into that table, DUNDi is the (scalable!) protocol meant to perform this task for you. Clearly, using a shared sipregs table has its own set of problems; rather than sticking to your flawed configuration, I would think that you would jump at the chance to fix it. -- Tilghman -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime SIP, multiple AX servers question
3 jan 2011 kl. 00.26 skrev Bryan Field-Elliot: Normally, no matter which Asterisk server an ATA connects to, we get our database fields filled out correctly, such as regseconds, lastms, ipadr, etc. However, with some ATA's we are experiencing a problem as follows: 1. ATA reaches its re-registration timeout, which we typically configure to be 60 minutes. 2. ATA re-queries DNS SRV record, and ends up re-registering with a different AX server than it was on previously. 3. The new AX server updates the Realtime DB fields (regseconds, lastms, etc). 4. The old AX server, after a few more minutes, notices that the ATA has vanished, and therefore clears out these same fields. Oh, that's an interesting observation. Depending on how you see it, it's a bug or a feature request. Code-wise what you could do is that Asterisk could retrieve the information from realtime. If the sysname is not the same as the systems, it let the information be. If it's the same sysname, then erase the information. /O -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime SIP, multiple AX servers question
Thanks Olle. Do you suppose I am the first Asterisk user to discover this behavior? I would find that hard to believe that I'm the first person to notice... Your idea for how to deal with sounds reasonable.. Thank you, Bryan On Jan 4, 2011, at 12:18 AM, Olle E. Johansson wrote: 3 jan 2011 kl. 00.26 skrev Bryan Field-Elliot: Normally, no matter which Asterisk server an ATA connects to, we get our database fields filled out correctly, such as regseconds, lastms, ipadr, etc. However, with some ATA's we are experiencing a problem as follows: 1. ATA reaches its re-registration timeout, which we typically configure to be 60 minutes. 2. ATA re-queries DNS SRV record, and ends up re-registering with a different AX server than it was on previously. 3. The new AX server updates the Realtime DB fields (regseconds, lastms, etc). 4. The old AX server, after a few more minutes, notices that the ATA has vanished, and therefore clears out these same fields. Oh, that's an interesting observation. Depending on how you see it, it's a bug or a feature request. Code-wise what you could do is that Asterisk could retrieve the information from realtime. If the sysname is not the same as the systems, it let the information be. If it's the same sysname, then erase the information. /O -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime SIP, multiple AX servers question
On Tuesday 04 January 2011 09:40:56 Bryan Field-Elliot wrote: Thanks Olle. Do you suppose I am the first Asterisk user to discover this behavior? I would find that hard to believe that I'm the first person to notice... It wasn't designed to do this. While you can have the same sippeers table for multiple servers, you really should have a separate sipregs table for each backend server. The reason why is that some mappings depend implicitly on the host to which it was registered. For example, if a phone is behind a NAT, then the external port is dependent upon the same host responding. If a different host tries to communicate to that external port, some NAT devices will not route the packet properly. This is especially true for SIP over TCP, but it's also true for UDP packets. (Routing packets back through a NAT without verifying the sending IP is a security risk.) Probably more appropriate for your case is to use DUNDi to coordinate your machines as to which server presents holds the registration for any specific phone. -- Tilghman -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Realtime SIP, multiple AX servers question
We have several Asterisk servers (1.6.2.15) all configured for Realtime, all backed by the same database. The Asterisk servers are all listed under DNS SRV records, and SIP ATAs find us this way. Normally, no matter which Asterisk server an ATA connects to, we get our database fields filled out correctly, such as regseconds, lastms, ipadr, etc. However, with some ATA's we are experiencing a problem as follows: 1. ATA reaches its re-registration timeout, which we typically configure to be 60 minutes. 2. ATA re-queries DNS SRV record, and ends up re-registering with a different AX server than it was on previously. 3. The new AX server updates the Realtime DB fields (regseconds, lastms, etc). 4. The old AX server, after a few more minutes, notices that the ATA has vanished, and therefore clears out these same fields. Is there any way to fix this problem? We need to know if ATA's go offline, but, we don't want them caught in this endless loop where our multiple AX servers are out-guessing eachother and overwriting valid data in the database. Our realtime options in sip.conf are as follows: rtcachefriends=yes rtsavesysname=yes ;rtautoclear=yes ;ignoreregexpire=yes Because we are using rtsavesysname, a perfect solution seems like it might be along the lines of If an ATA disappears, empty out the RT database fields ONLY if it's last regserver was this one. Is this possible? Thank you, Bryan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
