Obi Support,
Due to ongoing DDoS attack on CallCentric SIP registration servers, a bug with how Obi generates DNS requests has come to light. It is more of a DNS design spec thing but if fixed can really make Obi a market leader in analog ATAs.
While pointing Obi to some of the other DNS servers appears to work, the issue is how Obi deals with the presence of truncated flag in DNS response if present. I have attached the link to the thread which discusses this dns design spec in detail.
http://www.dslreports.com/forum/r27641748-DNS-SRV-Callcentric
The new dns srv records contain a lot of server instances than is being returned in the abbreviated list. The result is, while Obi does work with the abbreviated list of srv dns records returned from some of the other dns servers, the full list is not being utilized because Obi does not requery the dns with TCP based dns request on the presense of trancated flag in UDP dns reply.
As pointed out earlier, your attention to this detail will really set Obi apart from the other ATAs on the market today.
Thanks,
Hiranmoy
Please open a ticket with them, don't rely on them reading the forum...
Ok, I just opened a support ticket. Thanks.
In fact, I am hoping more Obi users than just me get interested in this issue, since as per a recent post by "iscream" (one of the CC support engineers who posts on dslreports.com), the list of srv records planned to be added to dns replies is only expected to grow.
As it is, only a subset (11) of it is being returned that to only by some dns servers, while CC has add @ 20 of them with a reference to add even more.
Lets see where this lands....
I'll jump in here in support of a fix also. See this thread (http://www.obitalk.com/forum/index.php?topic=4394.msg28867#msg28867), I sure the issues here and in the linked thread are one in the same.
+1 for a fix. Callcentric now has 40 servers:
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha9.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha10.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha11.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha12.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha13.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha14.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha15.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha16.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha17.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha18.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha19.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha20.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha1.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha2.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha3.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha4.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha5.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha6.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha7.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha8.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha9.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha10.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha11.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha12.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha13.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha14.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha15.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha16.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha17.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha18.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha19.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 5080 alpha20.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha1.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha2.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha3.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha4.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha5.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha6.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha7.callcentric.com.
_sip._udp.callcentric.com. 32 IN SRV 20 0 10123 alpha8.callcentric.com.
My Obi 110 was crashing randomly and frequently until I put X_ProxyServerRedundancy back to it's Default setting.
Turning off ProxyServerRedundancy stopped it from crashing immediately.
My tests showed that it didn't matter if I used callcentric.com or srv.callcentric.com for the Proxy as long as whatever servers you are using send the "abbreviated" list of servers. Just be sure X_DnsSrvAutoPrefix is checked to get the benefit of their new server setup. Until [and If] Obi is able to make the DNS change for TCP that has been requested, it seems redundant Proxy Servers won't work.
Turning off ProxyServerRedundancy stopped my Obi from crashing immediately.
Be sure both X_ProxyServerRedundancy and X_SecondaryRegistration have Default checked.
*EDITED* I just remembered there was a note from Obi about the 2744 firmware for the 110 - Proxy redundancy fail-over then resume improvement... Something may have broke (or been made worse) with this Build. Haven't tried reverting to the previous build. I opened a ticket with Obi.
Quote from: ProfTech on October 25, 2012, 02:34:17 AM
My Obi 110 was crashing randomly and frequently until I put X_ProxyServerRedundancy back to it's Default setting.
Turning off ProxyServerRedundancy stopped it from crashing immediately.
I saw the same repeated crash and reboot cycles on my Obi 100 and came up with the same solution. I was on an earlier firmware build and upgraded to the 2744 build to try to fix it (which it didn't), so I don't think it was something that 2744 introduced.
I have no idea why, but I have been using the setting recommended by CC (with X_ProxyServerRedundancy checked) for over 2 weeks without issue.
Quote from: VOIPisGreat on October 25, 2012, 06:08:28 PM
I have no idea why, but I have been using the setting recommended by CC (with X_ProxyServerRedundancy checked) for over 2 weeks without issue.
other than the X_ProxyServerRedundancy checked, they have changed the recommended settings twice in the last 10 days.
Quote from: jimates on October 25, 2012, 11:01:57 PM
other than the X_ProxyServerRedundancy checked, they have changed the recommended settings twice in the last 10 days.
While that is true, there's also a lot of conflicting and overlapping info in their recommendations, current and recent.
For example they have step 1 as power cycle all hardware, double check firewall. As was pointed out on dslr, is this to be done every time you change dns settings?
Step 2 if current config works do not change anything, and then "**IMPORTANT: We recommend using DNS SRV Settings for all configurations that support them," yet just below that for the obihai settings the dns srv prefix field is not listed.
It also says for outbound proxy "callcentric.com OR srv.callcentric.com (You can use either server, please test and configure this setting accordingly)"
Then step 3 says use these DNS servers, . . . . then "*The above listed DNS Servers are suggestions that have been successfully tested. You can use any DNS Servers provided that they resolve our SRV Records properly." Exactly how do I know if my isp provided DNS servers resolve the SRV records properly, is that what is causing the intermittent issues on the Obi device?
Quote from: jimates on October 25, 2012, 11:01:57 PM
Quote from: VOIPisGreat on October 25, 2012, 06:08:28 PM
I have no idea why, but I have been using the setting recommended by CC (with X_ProxyServerRedundancy checked) for over 2 weeks without issue.
other than the X_ProxyServerRedundancy checked, they have changed the recommended settings twice in the last 10 days.
I used the first setting recommended by CC and it worked ever since so I didn't check and change any settings after that initial change.
I also support fixing this bug.
Using large lists of SIP servers, propogated via SRV messages, will become the normal way to send registration information. The attack on Callcentric is going to force all providers to take similar measures and this is one of the ways that hardware on the users' end will make their fixes usable.
Please take this very seriously, this DDoS attack is going to hurt the VOIP industry as a whole unless all parties to this incorporate whatever measures are needed to prevent its recurrence. Certainly allowing TCP SRV messages with large lists of servers should be a reasonable response.
garys_2k,
+1
+1 for a fix.
+1 and annoyed.
Also finding that my reboot of the system in the direct interface (via IP address) does NOT really reboot. The "Reboot Required" remains, and the UpTime hasn't reset.
+1 for me
obi100 was quite unstable for callcentric because of SRV setting problems. My android 4.1 csipsimple has no problem using callcentric SRV feature. This DNS feature needs to be upgraded to utilize the full feature of callcentric to fight back attacks
I too would like a fix! It would also be nice if Obi made any comment at all about this. I would be annoyed, but unfortunately this is modus operandi for Obi as we've all seen... ::)
+1 and about ready to slit my throat.
FIX IT!
You can request beta here:
http://www.obitalk.com/forum/index.php?topic=4470.0
Dump CC ?
Quote from: lhm. on November 01, 2012, 05:59:28 PM
Dump CC ?
Two problems with that. 1) The bug should be fixed, CC or not and 2) I haven't found an alternative provider that provides e911 and allows me to pass in my calls for CID for $1.50/mo.
(And I understand I am getting what I pay for ;D )
Tom
I agree, I would not dump CC at this moment.
I just got my home power back today. We here at CT are not as bad as NYC, but I can appreciate the effort and difficult CC is facing now.
Feature wise, cost etc makes CC still a good bet for obi device on E911. I am also using CC now with android phone, which is fine working now on DNS SRV CC methods.
I got beta software installed and tested. callcentric line 2 GV line 1. all worked except that I noticed below one issue:
long delay on ringing CC. It took 1 ring or more to ring. after ringing , talking seems to be fine on CC. GV was also fine with no dropped call or obi reboot.
settings I used:
set up CC by easy mode first, then enter expert mode obitalk,
X_DnsSrvAutoPrefix is checked and leave everything else default.
Have asked several times for the firmware. Can't even have a call last more than 2 minutes before it drops. Either through GV or CC. Ordered a Cisco SPA112 today. Will have it tomorrow and I'll compare. Maybe saying goodbye to Obi!
Got the SPA112 today. Works beautifully except that you can't configure two sip providers on one line. ARRRGGGGHHH!!! WTF, over? Need firmware already to fix your proxy mess since you can't deploy Arbor and stop a DDoS attack like most companies!
Ok... I have to give a shout out to the Obi support team! Once I wised up and followed the process by submitting a support request, they made it happen! They updated my Obi100 with a newer firmware and viola, it works!!!
Because CallCentric has not setup the proper infrastructure to protect themselves from a DDoS attack, they made some major changes. Once they made some of their "proxy" modifications it crippled the Obi. Again, props to Obi! As a side note, if you expect other SIP gateways (Cisco SPA112) to perform the same as Obi, learn from me, they don't. The Cisco SPA112 does NOT allow you to provision two SIP providers on one line. Major drawback. They do already have the functions to deal with CallCentrics' multiple proxy and DNS environment, (Wow, an Arbor deployment would've been simpler) but there are some trade off's!
Thanks Obi for making your product even stronger and making me a believer!
I'll throw my hat in the ring for a fix as well. Unfortunately, as I used CC for my business, I had to drop them and go back to Cox. I feel like I went back to 1970's Ma Bell technology. The reliability is there, but the quality is no better, and none of the features. I miss CC :(
I don't have any comment on the Obi 202 but since Callcentric made their last set of changes, my 110 is working fine and I also have a 100 that is stable even with the standard Build 2744 firmware. I still believe that Obi putting in the TCP code for DNS is probably the correct thing for them to do for future compatibility but it doesn't seem to be required now for use with Callcentric.