replied: 503 Service Unavailable; warning: ; internal

[3397premier]

We are getting a ton of these errors and I am not sure how to resolve. I am hoping someone can help me out. We get these 503 errors when we try to make an outbound call. It gives a busy signal and then hangs up, try again and it does the same. When you try a third or fourth time it works. All users will encounter this same problem at the same time for several seconds and then it goes away. I put below an example of what we are seeing in the 3CX trace files. We have tested with another SIP provider and did not have any issues. Our current SIP provider says they do not see anything coming from us when this happens. We just use their IP for connecting no host name. Please let me know if you need additional information.

Logs:

10:16:22.086|.\Dialog.cxx(370)|Debug8|Resip|::ResipLoggerialog::dispatch: SipResp: 200 tid=f37e3c7ab9564b1d cseq=NOTIFY [email protected] / 38 from(wire)
10:16:22.086|.\UserProfile.cxx(158)|Debug8|Resip|::ResipLogger:Found credential for realm: realm=3CXPhoneSystem user=internal3CXPhoneSystem
10:16:22.132|.\ConnectionManager.cxx(243)|Trace5|Resip|::ResipLogger:Exception writing to socket 1276 code: 10061; closing connection
10:16:22.132|.\ConnectionBase.cxx(89)|Debug8|Resip|::ResipLogger:ConnectionBase::~ConnectionBase 063E8AF8
10:16:22.132|.\TuSelector.cxx(85)|Trace5|Resip|::ResipLogger:Sending ConnectionTerminated [ V4 199.167.204.41:5060 TLS target domain=199.167.204.41 mFlowKey=1276 ] to TUs
10:16:22.132|.\DnsResult.cxx(143)|Debug8|Resip|::ResipLogger:Remove vip 199.167.204.41(1)
10:16:22.132|.\dns\RRVip.cxx(97)|Debug8|Resip|::ResipLogger:removed vip 199.167.204.41(1): 199.167.204.41
10:16:22.132|.\TransactionState.cxx(1738)|Trace5|Resip|::ResipLogger:Try sending request to a different dns result
10:16:22.132|.\TransactionState.cxx(1633)|Trace5|Resip|::ResipLogger:Ran out of dns entries for 199.167.204.41. Send 503
10:16:22.132|.\Helper.cxx(375)|Debug8|Resip|::ResipLogger:Helper::makeResponse(SipReq: INVITE [email protected]:5060 tid=841e2163b6337732 cseq=INVITE contact=50.78.224.65:5060 / 1 from(tu) code=503 reason=
10:16:22.133|.\DnsUtil.cxx(145)|Trace5|Resip|::ResipLogger:local hostname does not contain a domain part 3CX
10:16:22.133|.\TransactionState.cxx(2112)|Debug8|Resip|::ResipLogger:Send to TU: TU: DialogUsageManager size=1

SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TLS 172.17.0.31:5061;branch=z9hG4bK-d8754z-841e2163b6337732-1---d8754z-;rport
To: <sip:[email protected]:5060>;tag=ae2c131b
From: "6123269231"<sip:[email protected]:5060>;tag=0560102d
Call-ID: MmI0MzcwMmQyYWMwMmI4YTM1MGZkZmZmMDYwOTE2MjQ.
CSeq: 1 INVITE
Warning: 499 3CX ""
Content-Length: 0

 

[lneblett]

Unusual log, but what strikes me is the IP. I am guessing that the example is to and from the same location? The IP is the same for both "From and To". There appears to be an issue in the DNS and for whatever reason the IP of your SIP (looks like Comcast in Minneapolis) provider is not being found; hence why they see nothing. Does the registration show to be good? This would also explain why they do not see anything.

To be safe, I suggest checking your network settings, firewall checker (although I doubt it will find anything given that you can use a different provider with no issue) and try a different DNS server.

 

[3397premier]

Yea, registration always looks good when I check it. Even when getting those errors. I can ping the IP just fine, even though by the time I ping the issue has passed. It usually only last for a few seconds, but long enough for us to not make any calls for that time period. I updated our VOIP provider to a host name rather then the IP to see if that is better, but from what it sounds like, this is most likely a ISP issue with their DNS records, correct?

I have two internal DNS server and have tried both not that there is much difference as they both use the same external DNS entries. I have also tried Comcast DNS records on the server as well bypassing my internal but still have same issue. I tried an open DNS as a 3rd and 4th choice on priority, but still a no go. Its funny cause after you try the number 3 or 4 times in a row it eventually works. If this is ISP related that would be good as they are always willing to correct whatever issues. Let me know what you think.

Thanks for the help.

 

[lneblett]

I would leave set to IP as trying to resolve to the FQDN is an added step and produces the same result. You could try and change the order of the DNS server entries, but it looks like you did this. You could try 8.8.8.8 which I think is Google and see.

I see 4 potential causes:

1. DNS having issue resolving, but seemingly unlikely given that you can ping the IP. (no longer seems likely, but still may be worth one more try)
2. Network transport issues with Comcast (possible, but also low on the list as I would tend to think it would not be intermittent). What about tables in switch, could they be corrupt and might a reboot of the network change things? (again I think low, but may be worth a try). You might also try http://www.pingtest.net and observe the results. At least it may give you a feel for the quality of the connection (java will need to be installed).
3. SIP provider having issues and either unaware or not willing to come clean. (possible, but others would likely have same issue and provider would work to get it resolved)
4. Settings with how provider wants to see your communication and all is not set correctly in the outbound parameters under VOIP provider. (Possible, but they should be able to see and advise is data stream meets their requirements and all). Given that you can make calls, this seems remote as well.

And I assume that your public IP is fixed? I also assume that you have stopped and restarted the 3CX services.

Am quickly running out of options. I can only guess that the machine has plenty of resources available, that nothing quirky like anti-virus or some other background process is getting in the way or commandeering the 5060 port for a few seconds.

You indicated that you tried another SIP provider with no issue and assuming that it was a fair test by which I mean that there was enough time and traffic to closely emulate that of your current provider so that if the issue were going to arise it would have, then I would suggest you call the current provider and see what help they can offer. You also may find more with a wireshark capture.