News:

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

Main Menu

SOLVED: Suddenly OBi's won't work with Asterisk — port registration issue

Started by MichiganTelephone, February 05, 2011, 11:36:29 AM

Previous topic - Next topic

MichiganTelephone

EDIT: For me the problem turned out to be that I had set "nat=never" and changing it to "nat=yes" fixed the problem.  Keep reading if you want to see what we went through to figure that out!

I have been beating my head against the wall, so to speak, for the last three hours or so and am getting nowhere.  I first noticed it when I tried to use the SP2 slot on my OBi100 as an Asterisk trunk (similar to what I'd done with the OBi110, but I was going to try using it as a gateway to Google Voice) and it didn't work, and then I noticed that the OBi110 was having the same issue.

The problem is this:  When you reboot the OBi, it will at first register normally with Asterisk.  But then, between about 15 and 30 seconds later, it appears that it attempts to re-register on port 65535, which is a big no-no with Asterisk, apparently.

Just to make sure it wasn't something I was doing wrong I disabled SP2 entirely, and used the SIP Account Wizard for ITSP Configuration to set up the extension on SP1 (I have done this before and it worked great). When the device rebooted I watched it do this:

   -- Registered SIP '234' at 192.168.0.33 port 5060
(... about 20 seconds later ...)
   -- Registered SIP '234' at 192.168.0.33 port 65535

When this happens, I can still make outgoing calls from the connected phone, but any calls from another extension TO the phone don't go through.  None of my other extensions do this and while I can't be 100% sure, I believe this problem developed overnight.  I didn't make any changes (until this happened, and then I made serveral attempts to fix the problem, all of which proved fruitless).  I did install the new firmware last night but tried going back to the previous version and that didn't help, so now I'm back at the new firmware again.

If I try to register the trunk on SP2 the exact same thing happens.

So at this point I can't use either of my OBi's with Asterisk, and I have no idea what caused this problem or even exactly when it started.  If anyone has any thoughts on why this is happening I'd sure like to hear them.

Added comment: One other thing I have noticed is that even though I never changed the port setting on SP2 (that is to say, the ProxyServerPort in ITSP Profile B reamis set to port 5060), the initial connection (and until this latest problem, the only connection) to the Asterisk server occurred on port 5061.  But if I tried actually changing the ProxyServerPort to 5061, it wouldn't connect to the server at all!  So if I have both SP's enabled I see this:

   -- Registered SIP '234' at 192.168.0.33 port 5060
   -- Registered SIP '1112223333' at 192.168.0.33 port 5061
(... after 15 - 20 seconds, at exactly the same time ...)
   -- Registered SIP '234' at 192.168.0.33 port 65535
   -- Registered SIP '1112223333' at 192.168.0.33 port 65535

(Obviously the numbers have been changed)

Question:  Does rolling back a firmware version undo EVERYTHING that the new firmware might have changed?  Because seriously, the only thing that has changed in this entire setup is that I applied the new firmware last night, and then didn't really do any testing (I may have made one quick call to see if the phone rang but probably did that within the 15-second window after the device rebooted).  But rolling back to the previous version didn't fix the issue, so now I'm just wondering if the new firmware changes something that going backwards won't undo.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

obiliving

I assume you mean OBi is sending REGISTER to 192.168.0.33 port 5060; then
30 seconds later, OBi starts sending REGISTER to the same IP but at port 65535, correct?

Do you use a domain name or IP address for the SIP ProxyServer on SP1 or SP2?
If you use domain name, it is possible that the OBi picks up the strange port number from
DNS SRV lookup. A wireshark capture should reveal this.


MichiganTelephone

obiliving, your first paragraph is correct except that the IP address shown is that of the device - those messages were printed by the server so it's showing the IP address of the device that's attempting to connect.

In my OBi configuration I use a dotted IP address because the server is on the local network.  I haven't changed that since I got the device.

Wireshark?  Is that some kind of fish, or something that networking gurus use?  ;D  Seriously, from what little I know of wireshark, it would be extremely difficult for me to get it working and get any useful data out of it.  VoIP I know (up to a point), and telephones I know, but networking is still something of a black art for me, once you get past basic things like setting up a static IP address.  I did once set up a VPN, but it took me close to a month to get it working and I still say it was one of the hardest things I ever did (with a computer, anyway).

As I say, the thing that mystifies me is that this thing has been working great and as far as I can tell the problem occurred around the time I installed the firmware update.  That MAY be coincidence, but I cannot think of anything else that might have caused this problem to suddenly manifest.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

obiliving

It's clear now. Asterisk is seeing REGISTRATION packets originating from the OBi (the device)
from port 65535 after the initial REGISTER. So forget what I said about DNS SRV.

The short answer is, I don't think it is related to f/w upgrade/downgrade.

Since the initial REGISTER is correct, it's not related to OBi's config either.
It's highly unlikely that OBi will change its SIP port after 1 REGISTER. It would just reuse the same
SIP socket until it reboots. Especially when this problem happens, both SP1 and SP2 appear
to originating packets from port 65535 (or -1 in 16-bit signed).

The default SP1/SP2 registration period is 60s; and OBi renews registration roughly half-way to
expiration or about 30s by default. So the 2nd or subsequent REGISTER happens about every 30s.
It does appear that somehow this Asterisk might have a problem when updating/renewing a
client (or just the OBi's) registration.
(But to identity which device is at fault, the easiest route is still using something
similar to wireshark. Sorry). Do you have any other network entity in between the OBi and Asterisk,
that might change the IP packet headers from OBi? Perhaps try rebooting those in-between devices,
including the Asterisk server.


A not-very-good work around for now is to set this REGISTRATION time on OBi to be a very very large number, such as 7200s or more (whatever biggest your Asterisk will take); so you can continue to do your more important tests. ... and get a wireshark trace when you have time to come back to this problem.

Just a thought.

I will see if I can reproduce it using the latest f/w from OBiHAI and provide more feedback.



MichiganTelephone

Okay, as it happens I have another Asterisk server I can test with that's not on the local network.  If I make SP1 an extension on that server it will register, although it does it with a funny port address:

   -- Registered SIP '333' at xxx.xxx.xxx.xxx:1128
      > Saved useragent "OBIHAI/OBi110-1-0-2" for peer 333

In this case it doesn't matter if I use the dotted IP address of the server or the human-readable domain name, it still comes in and hold the connection (at least so far).  The differences are:

One server is on the local network the other is not.
One server (the local one) is Asterisk 1.4, the other is Asterisk 1.8
On one it initially connects on port 5061 and then loses the connection, on the other it connects on port 1128 (???) and seems to hold the connection.

Don't know what to make of that.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

obiliving, I did reboot the Asterisk box earlier today and it didn't help.  The only thing between me and it is a switch,  and I power cycled that, and it didn't help.

When I set the registration time to a bit longer (like 300) it does delay the onset of the problem, but doesn't eliminate it.  When I set it to 7200 it still doesn't eliminate the problem, but as you might expect it takes about a half hour or more for it to start.

One interesting thing I note with the OBi is VERY short qualify (ping) times reported by Asterisk, on the order of 3 ms, whereas all the other connected equipment on the local network is running at anywhere from 9 to 22 ms.  I keep wondering if something's in a "race" condition and when you use it with a distant server the added turnaround time eliminates the problem - wish I had a way to test that theory.

I could send you (in email) a sip debug trace from Asterisk showing the problem occurring, but all I really see is that it suddenly changes ports, with no indication as to why that might happen.  Then again, I'm not always entirely sure what I'm looking at.  But one thing I do notice is that once the problem occurs, the OBi110 seems to get quite "chatty", sending many more packets than I would expect to see in a given period of time.  It's as if someone turned on the spigot — you don't see a delay of more than three or four seconds tops between groups of packets coming from the device.  Once it's rebooted it gets a lot "quieter" until the problem starts again.

I don't think you quite understood that I really don't have any way to run Wireshark here.  As I understand it you have to be able to intercept the packet flow.  I saw it used once once or twice (or maybe it was "Ethereal" or something like that) but didn't really understand what I was seeing and don't recall much about it, other than that I think a computer with two network cards was used in the process.  It's not that I couldn't run the program itself (I'm pretty sure there's a Mac version) but I don't know how I'd intercept the packet flow, since my Mac Mini only has the one network connection.  But if you have any suggestions as to how it might be accomplished, let me know.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

OBiSupport

Hi

Do you have any special setting in your sip.conf?
Pls check your "bindport", are you specifying it to some specific value ?

From your asterisk linux machine, you can also run
"netstat -an | grep <your_asterisk_ip_address>"
This command displays all the port that your PC currently is listening at.
Are you seeing lots of entries for udp, other than 5060 ?
What you said earlier about the registration used to be ok,
are you registering with a different peer userid now ?
If yes, do you have setting for "port" under that [userid] in sip.conf?

What is this unit's OBi number ?
For privacy, you can email this to support@obihai.com
Please register the unit to OBiTALK as your other Device.

PS: Do you have a softphone ? xlite perhaps ?
Does this softphone also behave the same way ? changing registration port ?

-Obihai Support Team

MichiganTelephone

Just so you know, I run FreePBX so most of the configuration is handled by that.
There is a bindport = 5060 line in sip_general_custom.conf

Are you sure that netstat command is correct?  When I run that I see only three UDP entries and none for port 5060, yet I know that port is used by other devices on the network.  If I run it without the grep then the only reference I see to 5060 is this:

udp        0      0 0.0.0.0:5060                0.0.0.0:*

There are several other UDP ports listed when I run it without the grep.

With regard to the peer registration for the extension, the port is set in the FreePBX GUI and by default it is always 5060, though it can be changed - but it hasn't been for this extension.

I will send you more information in e-mail.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

I THINK I'VE FOUND THE PROBLEM!!!

Though I do not have any idea why it wasn't a problem until today.

In the post from OBIsupport they suggested that I register the unit to OBiTALK as your other Device.  I was reluctant to do that on my OBi110 but got to thinking that maybe I should try setting up another extension on my OBi100.  And to make a long story short, it worked and did NOT have the problem.

So then I tried the using the exact same settings on the OBi110, except I did not change the extension, and still had the problem.  So now I was getting really suspicious that something was different in my FreePBX configuration.  Well, there was.  On the extension that didn't work, I had nat set to never, which seems logical for an extension on the same LAN and which is the setting I've always used with Linksys/Sipura devices without any issue (again, only for devices on the same LAN).  But when I set up the OBi100 extension I used one that I'd previously used with a softphone and it had nat set to yes, and that seems to be the difference!

So, apparently you have to use nat=yes for the OBi devices, even if they are on the same LAN!  I'm still testing this theory but so far it seems to be working, however I'm still extremely puzzled as to why this problem didn't manifest until today, since I had used the nat=never right from the start.


Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

It's still working, so I revised my article to show nat=yes instead of nat=never, so hopefully nobody else has to deal with this.  Still really curious why it didn't seem to make a difference until today, but I'm just happy it works.  A big THANK YOU to all who offered suggestions and advice, I really appreciate all the help!
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

One more thought...

There is an interesting discussion on the variations on Asterisk's NAT parameter at http://www.voip-info.org/wiki/view/Asterisk+sip+nat — it turns out that nat=never is probably "never" an appropriate setting for many devices, since it was introduced to solve a specific issue with certain types of hardware. Just for fun I tried setting nat=no on the settings for these devices and so far that seems to work as well as nat=yes (and seems more appropriate for a LAN).  I'm not sure when I first started using nat=never for internal extensions but it probably dates back to the days of Asterisk@Home and some "recipe" I saw online.

Even reading that page on voip-info.org it's confusing as to whether it's better to just always use nat=yes, or if it really is more appropriate to use nat=no if the device and server are on the same LAN. Just in passing I'll note that  setting nat=yes seems to more consistently hold the qualify (ping) times down to around 3 ms, while using nat=no sometimes seems to result in slightly higher times (but generally only 1 or 2 ms higher).

Still, the thing I can't wrap my head around is that the OBi110 worked great with the nat=never setting for nearly a full week.

Speaking of that 3 ms ping time, that's another thing I can't wrap my head around — the next lowest ping time for any device on this LAN is 9 ms and the average is more in the 12-13 ms range.  These babies are fast! :D


Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.