SIP Troubles
-
@LAH3385 said:
@Dashrender said:
@LAH3385 said:
I have a similar situation but on a completely different platform. In my case we are on PRIs with NEC PBX SV9100 phone system. All phones connected via LAN. The first couple of weeks I would receive reports that phone are "locking up" meaning they are not responsive to any thing. The issue usually resolve by soft reset the phone.
It is very annoying to end-users. After a whole week of monitoring and troubleshooting we found the problem with DHCP and Subnet. I was not aware that our scope on DHCP was running out. When the phones were installed half of them picked up subnet .1.x while the other half picked up subnet .2.x. This cause issue because the phone sometime lose connection to the PBX phone system.
The fix for us was to move everything to static IP address and put every phone on the same subnet. The issue was resolved and I have no heard of anything since.
I highly doubt this is the same cause as to what OP is experiencing, but I thought it is worth to shade some light.
That's an interesting problem.
So you were deploying to different subnets worth of IPs (assuming /24) on the same VLAN?
What was the cause for the phone to not be able to reach the PBX? a router problem?
That... I don't know the real cause. I am too noobish to understand how signals are translate from phone to PBX and vice versa. My uneducated guess what was the problem would be that... it's the router fault.
Sorry I just don't know what happened.
We only have one floor/office so everything is connected via LAN. Unlike yours which run across buildings and VPN.mind If I ask you position in the company? Are there full time IT personal there?
-
@Dashrender said:
@LAH3385 said:
@Dashrender said:
@LAH3385 said:
I have a similar situation but on a completely different platform. In my case we are on PRIs with NEC PBX SV9100 phone system. All phones connected via LAN. The first couple of weeks I would receive reports that phone are "locking up" meaning they are not responsive to any thing. The issue usually resolve by soft reset the phone.
It is very annoying to end-users. After a whole week of monitoring and troubleshooting we found the problem with DHCP and Subnet. I was not aware that our scope on DHCP was running out. When the phones were installed half of them picked up subnet .1.x while the other half picked up subnet .2.x. This cause issue because the phone sometime lose connection to the PBX phone system.
The fix for us was to move everything to static IP address and put every phone on the same subnet. The issue was resolved and I have no heard of anything since.
I highly doubt this is the same cause as to what OP is experiencing, but I thought it is worth to shade some light.
That's an interesting problem.
So you were deploying to different subnets worth of IPs (assuming /24) on the same VLAN?
What was the cause for the phone to not be able to reach the PBX? a router problem?
That... I don't know the real cause. I am too noobish to understand how signals are translate from phone to PBX and vice versa. My uneducated guess what was the problem would be that... it's the router fault.
Sorry I just don't know what happened.
We only have one floor/office so everything is connected via LAN. Unlike yours which run across buildings and VPN.mind If I ask you position in the company? Are there full time IT personal there?
Yes. I am full time system admin.
-
@LAH3385 said:
@Dashrender said:
@LAH3385 said:
@Dashrender said:
@LAH3385 said:
I have a similar situation but on a completely different platform. In my case we are on PRIs with NEC PBX SV9100 phone system. All phones connected via LAN. The first couple of weeks I would receive reports that phone are "locking up" meaning they are not responsive to any thing. The issue usually resolve by soft reset the phone.
It is very annoying to end-users. After a whole week of monitoring and troubleshooting we found the problem with DHCP and Subnet. I was not aware that our scope on DHCP was running out. When the phones were installed half of them picked up subnet .1.x while the other half picked up subnet .2.x. This cause issue because the phone sometime lose connection to the PBX phone system.
The fix for us was to move everything to static IP address and put every phone on the same subnet. The issue was resolved and I have no heard of anything since.
I highly doubt this is the same cause as to what OP is experiencing, but I thought it is worth to shade some light.
That's an interesting problem.
So you were deploying to different subnets worth of IPs (assuming /24) on the same VLAN?
What was the cause for the phone to not be able to reach the PBX? a router problem?
That... I don't know the real cause. I am too noobish to understand how signals are translate from phone to PBX and vice versa. My uneducated guess what was the problem would be that... it's the router fault.
Sorry I just don't know what happened.
We only have one floor/office so everything is connected via LAN. Unlike yours which run across buildings and VPN.mind If I ask you position in the company? Are there full time IT personal there?
Yes. I am full time system admin.
Then you need to hire a IT Service Provider to help you get things cleaned up.
From the sound of your post, your network is a mess.
-
Getting this thread back on track.
My PBX vendor came onsite and did a remote session with Mitel. Mitel made several tweaks that solved nothing.
Then they added
5000 CP > System > Devices and Feature Codes > SIP Peers > SIP Trunk Groups > 9203 > Configuration >Route Sets > 1I'm not sure what this even does. My PBX vendor swears that they have never enabled this option before for any SIP trunks, including Cox.
Plus the fact that this has been working fine since November until Jan 29.
But shortly after this change, the errors stopped and calls have been working well ever since.
tosses hat in the air whatev's.
-
OK the problem seems to be gone.
My local vendor contacted Mitel and they offered the following fix.
as mentioned above, We've been on the SIP trunk since Nov/Dec, but now for whatever reason this change was required to make the problems stop... and they appear to have done just that.
-
@Dashrender what was the change? the entire section?
-
@JaredBusch said:
@Dashrender what was the change? the entire section?
yes the addition of the entire 1 option under Route Sets.
-
@Dashrender said:
@JaredBusch said:
@Dashrender what was the change? the entire section?
yes the addition of the entire 1 option under Route Sets.
That is setting your SIP to UDP Interesting.
-
@JaredBusch said:
@Dashrender said:
@JaredBusch said:
@Dashrender what was the change? the entire section?
yes the addition of the entire 1 option under Route Sets.
That is setting your SIP to UDP Interesting.
Interesting.. I stared at that for 20 mins trying to figure out what it was doing...
Isn't SIP UDP by default? if not, why would it need to be TCP?
-
@Dashrender said:
@JaredBusch said:
@Dashrender said:
@JaredBusch said:
@Dashrender what was the change? the entire section?
yes the addition of the entire 1 option under Route Sets.
That is setting your SIP to UDP Interesting.
Interesting.. I stared at that for 20 mins trying to figure out what it was doing...
Isn't SIP UDP by default? if not, why would it need to be TCP?
Honestly, SIP has no default that I am aware of. SIP works better over TCP and is explained decently in this thread.
RTP is a UDP default protocol.
-
Interesting. In my situation there are no routers only a switch between my PBX and their first box. And their box is locked down to only talk to my IP.
