News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obi200 trouble w/ voip.ms since ~Oct 12

Started by Steve_M, November 06, 2016, 07:23:47 AM

Previous topic - Next topic

Steve_M

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!

Mango

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.

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

Mango

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.

Steve_M

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.

Mango

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.

Steve_M

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.

Steve_M

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

drgeoff

The Surfboard SBG6580 is a modem and 4 port router. You have another router plugged in to that?

Mango

He must have it in bridge mode if he's getting a 76. address.

drgeoff


drgeoff

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?

Steve_M

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!

Mango

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.


Steve_M

Thanks again Mango!

Another successful call tonight, hopefully forever :)

Steve_M

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.

Mango

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.

Steve_M

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:

Steve_M

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.