leon032 Posted February 28, 2013 Posted February 28, 2013 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.
plexer Posted February 28, 2013 Posted February 28, 2013 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 Posted February 28, 2013 Posted February 28, 2013 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. 1
leon032 Posted February 28, 2013 Author Posted February 28, 2013 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 Posted February 28, 2013 Posted February 28, 2013 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 Posted March 5, 2013 Author Posted March 5, 2013 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 Posted March 5, 2013 Posted March 5, 2013 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 Posted April 17, 2013 Posted April 17, 2013 (edited) 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. Edited April 17, 2013 by Sampratt Thanks for the info, spam link removed
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now