[VOIP] Incoming calls

[leon032]

I wanted to see if you guys can give me idea where this issue might be arising from.

Scenario:

We have Comcast as our internet service provider in the office. We use a company called GPhone to provide us with our SIP trunk. For our hardware we have a German phone system called Innovaphone. We use the same hardware with different providers in many countries without any issues.

Problem:

Every once a week or twice a week (actually just randomly) we have issues receiving calls. The system shows as if everything is running OK but we can not receive call from an external number. We are able to call within the office and we can even call external numbers but can not receive incoming calls when the error occurs. The problem is that our technician in Europe says that he sees nothing on the logs and Comcast says everything is perfect on their side. I am still waiting on a response from GPhone. The only thing we can do is to disable the SIP on our system and then enable it again for it to start working correctly. It seems as if there is an error and the connection to the SIP is not established automatically. The problem is that we do not receive any errors so we do not know the phones are down until someone is informed that the calls cant go in.

I wanted yo know if anyone has any idea what could be the issue? I don't know if the issue can be through the provider of the SIP Trunk, the hardware, or ISP. Any suggestion will be really appreciated.

[FN-GM]

How do you usually fix it?

[plexer]

The only thing we can do is to disable the SIP on our system and then enable it again for it to start working correctly.

FYI

Ben

[jamesfed]

Ages ago we had a problem with our Lync 2010 (SIP and VoIP) where incoming calls would drop every now and again - turned out the issue was a combination of a faulty NIC in the virtual host that was running it as well as the power saving mode was turned on the power features on the virtual host server.

Fixed both of those and we haven't had a dropped call in months.

[FN-GM]

Oops sorry plexer I need glasses clearly!

[leon032]

Thanks Jamesfed for your response. In in our situation it can not be the Power Saving mode because other setups have been done the same in other locations with no issue. As for the faulty nic did you see anything that led to that conclusion in your logs? As I said before it really varies when it happens here. Last month we had no issues at all. Last week we had the issues three days in a row. Also when I check the events log I see entrie like these:


27.02.2013-10:05:44 Error 0x00060004 Major H323 Signaling Timeout(25->33)
27.02.2013-09:55:47 Error 0x00050002 Major RTP Excessive loss of Data
27.02.2013-09:41:22 Error 0x00070007 Major SIP Internal error on media negotiation

But according to our tech in Austria, the logs doesn't show why we lose connectivity with our SIP Trunk.

[jamesfed]

The only thing that brought us to thinking it was a faulty NIC was when we did a large sequential file transfer into the server - outbound it worked perfect every time, inbound we would start to see excessive packet loss.

[leon032]

So I thinking I might have found the problem the firewall was block the SIP.

Date Time 2013-03-05 17:13:54 Date 2013-03-05
Time 17:13:54 Level warning warning
Sub Type other ID 7
Virtual Domain root Src x.x.x.x
Src Name x.x.x.x Src Port 5060
Dst x.x.x.x Dst Name x.x.x.x
Dst Port 26877 Service 26877/udp
Protocol 17 IM and P2P Application N/A
Duration 0 Rule 0
Policy ID 0 Sent 0 B
Received 0 B VPN N/A
Src Interface wan1 Dst Interface root
Serial Number 41685417 Status
User N/A Group N/A
Carrier End Point N/A Application Name N/A
Application Category N/A Sent Shaper Bytes Dropped 0
Received Shaper Bytes Dropped 0 Per-IP Shaper Bytes Dropped 0
Sent Shaper Name N/A Received Shaper Name N/A
Per-IP Shaper Name N/A Identity Index 0
Message iprope_in_check() check failed, drop Destination Country United States
VPN Type N/A VPN Tunnel N/A
Profile Group Name N/A Sub Application Category N/A
Sub Application Name N/A Source Country United States

type=traffic subtype=other pri=warning status=deny vd="root"

I noticed that the source IP was our SIP.

[SchoolsBroadband]

Some routers have SIP ALG on them which can actually cause more problems even though they are designed to help SIP via a nat'd router.

If your router has ALG on by default try turn it off and that may also help fix the problem.

Dave

So I thinking I might have found the problem the firewall was block the SIP.

Date Time 2013-03-05 17:13:54 Date 2013-03-05
Time 17:13:54 Level warning warning
Sub Type other ID 7
Virtual Domain root Src x.x.x.x
Src Name x.x.x.x Src Port 5060
Dst x.x.x.x Dst Name x.x.x.x
Dst Port 26877 Service 26877/udp
Protocol 17 IM and P2P Application N/A
Duration 0 Rule 0
Policy ID 0 Sent 0 B
Received 0 B VPN N/A
Src Interface wan1 Dst Interface root
Serial Number 41685417 Status
User N/A Group N/A
Carrier End Point N/A Application Name N/A
Application Category N/A Sent Shaper Bytes Dropped 0
Received Shaper Bytes Dropped 0 Per-IP Shaper Bytes Dropped 0
Sent Shaper Name N/A Received Shaper Name N/A
Per-IP Shaper Name N/A Identity Index 0
Message iprope_in_check() check failed, drop Destination Country United States
VPN Type N/A VPN Tunnel N/A
Profile Group Name N/A Sub Application Category N/A
Sub Application Name N/A Source Country United States

type=traffic subtype=other pri=warning status=deny vd="root"

I noticed that the source IP was our SIP.

[Sampratt]

True now a days many commercial routers implement SIP Application-level gateway (ALG) and sometimes this cause problem and breaks SIP protocol make communication problems. When a UAC is switched on it sends a register signal to the proxy to receive incoming calls. this signal is modified by the ALG feature and routers just maintain the UDP connection open for a while after that time the port forwarding is ended and incoming packets are discarded by router.