After months of very stable service, I'm having a sudden issue with my Obi200 and voip.ms service.
Problems Initially manifested as calls ending to a dial tone at the 15 minute mark (+/- 10 seconds).
That continues and now there are two other issues:
* callers receiving dead air (no ring on my end)
* outbound calls receiving a message "<tri-tone> the number you have dialed <states number dialed> did not receive a response from the service provider"
Does still work sometimes, and I've even had 3 calls (out of about 15 attempts) last more than 15 minutes while the other 11-12 ended right at that magic 15 minute mark.
I've reset the Obi, and set it back up via the ObiTalk site - no change.
Hardware 1.4
Firmware 3.1.0 (Build: 5264)
RegisterExpires is set to 300
Appreciate any ideas & expertise!
Given that the issue often happens close to the 15 minute mark, the first thing I would suspect is a session timer attempting to refresh the session and failing.
The message "...did not receive a response from the service provider", on a correctly-configured ATA, often indicates corrupted NAT tables. This is probably also causing your calls to drop around 15 minutes.
Did you make any chances to your router around October 12?
Does your router receive a public IP address from your ISP, or do you have multiple routers?
Do you have your router's SIP ALG enabled? If so, try to disable it. If that's not possible, set your ProxyServerPort and RegistrarServerPort for the ITSP Profile configured for VoIP.ms to 42872, and set your X_UserAgentPort for the Voice Service configured for VoIP.ms to a random number between 20000 and 65535, for example 28746. You will need to use OBi Expert Configuration to make this change.
Are your X_KeepAlive settings (from within the Voice Service configured for VoIP.ms) set to defaults?
What router do you use? Do you have access to a different brand of router to test with, to confirm my guess that the router is the problem?
Let us know how things go.
m.
* no changes on my end, and nothing the ISP told me about (Eastlink, in Canada). Same modem/ISP/Obi I've had for months.
* Obi is connected directly to ISP's cable modem (Surfboard SBG6580). That said, I don't think I have a SIP_ALG setting accessible to me on that modem.
* Obi receives a public IP 76.x.x.x.
* X_Keepalive are all default checked - sharing values here in case the defaults could be somehow wrong
* * X_KeepAliveEnable () - unchecked
* * X_KeepAliveExpires (15)
* * X_KeepAliveServer () - empty/blank value
* * X_KeepAliveServerPort (5060)
* * X_KeepAliveMsgType (keep-alive)
* No alternate router (modem) easily accessible, though if all else fails I'll take the Obi to someone else's house.
I know I have power-cycled the modem since the 12th as a troubleshooting step, but not recently. Will complete that tonight, in case there was an ISP issue that's since been solved.
If issue reoccurs, I'll move on to "set your ProxyServerPort and RegistrarServerPort for the ITSP Profile configured for VoIP.ms to 42872, and set your X_UserAgentPort for the Voice Service configured for VoIP.ms to a random number between 20000 and 65535, for example 28746"
Also, Is there a way to turn on any detailed logging (voip.ms or Obi-side) that would give a more definitive error log?
Thanks much for the reply and ideas so far.
Quote from: Steve_M on November 06, 2016, 06:29:09 PM* Obi receives a public IP 76.x.x.x.
This is a problem. The OBi200 does not contain a firewall. (OBi202 does). The 200 should not be exposed to the internet without a router as it is vulnerable to DoS and other attacks.
Could you describe your network? Does your computer also receive a public IP or is it behind a router? If the computer is behind a router, perhaps you could put your OBi200 behind the same router.
Ouch, a rookie mistake on my part, thanks!
Currently, everything else on the network sits behind a router w/ DD-WRT loaded. That router gets a public IP WAN-side, and hands out 192.x.x.x on the LAN & WLAN side via DHCP.
I'll shuffle some wires around in the AM, and start reading up on NAT/port forwarding, etc.
DD-WRT should not require port forwarding (because your X_KeepAlive settings are correct). Plug the ATA in to the router and hope for the best, and let us know if you still have problems.
Did power-cycle the cable-modem last night.
Dropped again tonight at the 15 minute mark - sharp.
Just updated to these settings, and recycling the Obi again.
* ProxyServerPort to 42872 (was 5060)
* RegistrarServerPort to 42872 (was 5060)
* X_UserAgentPort to 28746 (was 5080)
Hoping to work out the kinks before I hide it behind my router, and risk adding another variable.
I followed the instructions here: https://www.obitalk.com/forum/index.php?topic=707.0 to set up syslog, hoping there will be some tidbit in the logs that will help pinpoint the issue.
Contacted my ISP - they don't think they chagned anything either...
For the sake of being thorough, I did get my firmware version.
SBG6580-8.9.0.0-GA-05-062-NOSH
Another update: I was getting a ton of spammy "stuff" in the syslog, so I've put the Obi behind my router.
The Surfboard SBG6580 is a modem and 4 port router. You have another router plugged in to that?
He must have it in bridge mode if he's getting a 76. address.
http://kb.sleepyshark.com/article.php?id=6
Disable SIP ALG on Surfboard SBG6580
Quote from: Mango on November 08, 2016, 07:57:29 AM
He must have it in bridge mode if he's getting a 76. address.
But if in bridge mode surely it should not be feeding the OBi and another router at the same time?
Confirming setup until yesterday:
SBG6580 Port 1 ==> DD WRT Router (WAN 76.x.x.x) ==> multiple LAN and WLAN devices in 192.x.x.x
SBG6580 Port 2 ==> Obi200 (WAN 76.x.x.x)
As of last night, the Obi200 is "just another device" on the LAN side of the DD WRT (192.x.x.x).
Only one long call attempt today, and it DID go beyond 15 minutes successfully.
Capturing syslog data during calls, until I catch one that drops at the magic 15 minutes. The syslog is MUCH less spammed behind the router. While it was still in the public space, I had 1300 log entries like this over the course of an hour:
[Nov 07 22:54:06][76.x.x.x]<7> ++++ ph tftp request=1; /x
... 14 more entries just like these ..., and 1200+ more in groups of 5-15 in the hour
[Nov 07 22:54:32][76.x.x.x]<7> ++++ ph tftp request=1; /x
I still don't see the connection between the spam and the 15 minute drops, except in a very generic "the Obi lost track of important stuff while it was dealing with spam" :)
Will test again tomorrow and report back, work permitting!
Quote from: Steve_M on November 08, 2016, 07:24:28 PMI still don't see the connection between the spam and the 15 minute drops, except in a very generic "the Obi lost track of important stuff while it was dealing with spam" :)
This is basically it. VoIP.ms sends a SIP packet to your ATA every 15 minutes to be sure the ATA is still online. As I mentioned earlier, this is called a session timer. When your ATA is being attacked, it does not respond to VoIP.ms, so VoIP.ms thinks your ATA has fallen offline and ends the call so that your balance doesn't get used up by a call that goes on forever.
Placing your ATA behind a firewall (which you've done) is the best solution.
I bet this is the type of attack that is occurring:
http://news.softpedia.com/news/600-000-tftp-servers-can-be-abused-for-reflection-ddos-attacks-501568.shtml
http://news.softpedia.com/news/ddos-attacks-via-tftp-protocol-become-a-reality-after-research-goes-public-504713.shtml
Your OBi200 was participating in a DDoS attack, and in the process, got DoSed itself.
Thanks again Mango!
Another successful call tonight, hopefully forever :)
Sad to report I'm back, at least half of my calls are still cutting off promptly at 15 minutes. Tonight two in a row at 15 minutes, yet two nights ago a 15 minute, followed by a 46 minutes that I ended on my own.
I do have logs from the syslogd thing for both drops tonight - anything I should be looking for in there?
voip.ms support team suggested changing my protocol to TCP, which I'll try next.
Well, that is unfortunate.
If you still see messages about tftp in your syslog, that would be useful to know.
You may also wish to run a ShieldsUP test: https://www.grc.com/ShieldsUP . Click Proceed, enter 69 in the box, and click User Specified Custom Port Probe. A result other than Stealth is a problem.
No mention of tftp at all.
Came back "Stealth".
I've been through the logs just before the disconnect, and see these entries
scrubbed my other party's phone number, and most of the content after the ":", but can share whatever is helpful.
[Nov 15 19:53:29][192.x.x.x]<7> [SLIC]:Slic#0 ONHOOK
[Nov 15 19:53:29][192.x.x.x]<7> sendto b84bd5d2:5060(638)
[Nov 15 19:53:29][192.x.x.x]BYE sip:1NPANXXXXXX@184.75.213.210:5060 SIP/2.0
Call-ID:
Content-Length: 0
CSeq: 8003 BYE
From:
Max-Forwards:
To:
Via:
Authorization:
User-Agent:
X-RTP-Stat:
[Nov 15 19:53:29][192.168.1.117]<7> RTP:Del Channel
[Nov 15 19:53:29][192.168.1.117]<7> RxFrom:b84bd5d2:5060
[Nov 15 19:53:29][192.168.1.117]SIP/2.0 200 OK
Via:
From:
To:
Call-ID:
CSeq: 8003 BYE
Server: voip.ms
Allow:
Supported:
Content-Length:
I'm realizing now that could be me ending the call locally once I realize the other party is not connected.
Still digging in the logs backwards from that point for other clues.
Quote from: Steve_M on November 06, 2016, 06:29:09 PM* * X_KeepAliveEnable () - unchecked
I missed this before. Now that your device is behind a router, X_KeepAliveEnable should be checked.
If my guess is right, you are experiencing the same problem, with a different cause.
Checking that box and going back to UDP - just so I'm only changing & testing one thing at a time.
Give the echo test (free) a call at 4443, check on it in 16 minutes, and let's see what happens!
17 minutes, so I'm 1 for 1!
Will report back in a few days.
Thanks again for your help & advice.
No luck, still dropping at 15 minutes. Thanks in advance if there's anything left to try :D
Quote from: Steve_M on November 18, 2016, 06:29:05 PM
No luck, still dropping at 15 minutes. Thanks in advance if there's anything left to try :D
I would suggest trying a different endpoint device to register to your VoIP.ms DID and see if you still have the problem.
You could download Phonerlite and configure it on your computer for your VoIP.ms DID. Phonerlite has pretty good Debug screens/logs.
Make sure your OBi no longer registers to VoIP.ms and that Phonerlite does. Make some phone calls using Phonerlite and see if you run into the same problem at the 15 minute mark. If so, check your debug screen to see what happened. If you don't have a headset (or microphone) for your computer you should be able to just call a radio station and let it play for the 15 minutes.
Some example numbers:
6415525046 Liberty Radio Network
7124326610 PBS News Hour
7124325335 BBC World Service
If you don't want to use your computer you could use a SIP client (CSipSimple or Zoiper) on a smartphone via WiFi. But I am unsure of the logging/debug capabilities of those SIP clients.
Thanks Taoman, I'll look into an alternate device.
In the meantime, I've been combing my syslog trying to find anything that seems inconsistent or error-like.
I do see a number of messages every 30-31 seconds, repeating as follows. Based on the block of text following each one, they seem to represent a REGISTER, OPTIONS, REGISTER, NOTIFY respectively. Lots of other text I can sanitize and share if this is worth pursuing.
[Nov 20 22:20:33][192.x.x.x]SIP/2.0 401 Unauthorized
[Nov 20 22:20:33][192.x.x.x]SIP/2.0 200 OK
[Nov 20 22:20:33][192.x.x.x]SIP/2.0 200 OK
[Nov 20 22:20:33][192.x.x.x]SIP/2.0 200 OK
A 401 is typical. It's the switch responding with a challenge, then your device sends back another REGISTER packet with the response to the challenge.
Going to start over.
1) Removed SP1
2) Deleted device from Obi site, and performed factory reset as instructed here: https://www.obitalk.com/info/faq/Troubleshooting-sec/How-to-Factory-Reset
3) Added device through Obi Dashboard (**5 #### process)
4) Completed manual setup here: http://wiki.voip.ms/article/OBi_100/110 (Manual Configuration Details section)
And now a test call to my cell phone.
Two questions please:
1) My test calls to the Echo Test (4443) have always worked - does that narrow down the source of the problem, or just luck?
2) What setting can I change to make the drop happen sooner? I'm not sure I see anything that is defaulted to 900 seconds. Probably sounds silly, but I'd rather iterate more quickly at this point.
2) As far as I'm aware, the OBi does not allow you to change the session interval.
Shot in the dark: what if you disable Service Providers >> ITSP Profile X >> SIP >> X_SessionRefresh?
The downside to doing this is if you hang up and due to a network issue VoIP.ms doesn't receive your BYE packet, and the other side also doesn't disconnect, the call would run for VoIP.ms's maximum time limit (probably 90 minutes or so). I would imagine this scenario would be exceedingly rare.
I have never actually tested this option, but I think it's worth a try.
No abruptly ended calls since the complete reset as described in my 11/22 post. (~5 calls successes >15min duration).
I wish I had a more specific setting/fix to share, but I don't.
Thanks again Mango & Taoman for your suggestions, and anyone else who gave my trouble some thought.
Appreciate the community that supports the device - without it, my Obi would already be at the recyclers! :)