Obi firmware bug

[HMishra]

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

[Rick]

Please open a ticket with them, don't rely on them reading the forum...

[HMishra]

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....

[CoalMinerRetired]

I'll jump in here in support of a fix also. See this thread, I sure the issues here and in the linked thread are one in the same.

[lacibaci]

+1 for a fix. Callcentric now has 40 servers:

Code Select Expand


_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.


[ProfTech]

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.

[RoyH]

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. 

[VOIPisGreat]

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.

[jimates]

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.

[CoalMinerRetired]

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?

[VOIPisGreat]

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.

[garys_2k]

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.

[QBZappy]

garys_2k,

+1

[rsriram22]

+1 for a fix.

[Rick]

+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.

[jxzz]

+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

[tome]

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...

[KC512]

+1 and about ready to slit my throat.
FIX IT!

[lacibaci]

You can request beta here:
http://www.obitalk.com/forum/index.php?topic=4470.0

[lhm.]

Dump CC ?