I have an AsteriskNOW server running well in central location, with all phones on the internal network running well.
I have another location where up until earlier this week my cisco 7960 phone was connecting across the internet to the server in the central location and has been for a couple of weeks.
Suddenly I started to get network interruption issues during calls so i rebooted my router and phone and the phone would no longer connect - lines have x next to them.
My iphone running 3CX app is still working fine over the wifi in thie remote location.
I have been looking at the logs on the AsteriskNOW server and am seeing the following error
[2013-02-08 00:52:56] ERROR[3023] netsock2.c: getaddrinfo(“82.xx.xxx.xxx”, “61605branch=z9hG4bK16124a21”, …): Servname not supported for ai_socktype
The ipaddress in the log file with the error is that of the Virgin Media ISP connection to the remote location. I am seeing it doesnt like the servername/hostname? Not sure why this is suddenly happening and whether Virgin Media have made some change which has upset AsteriskNOW.
Does anyone know how I can resolve this? Can i enter the host name somewhere in AsteriskNOW so that it accepts connections from this remote location - or am i going down the wrong route here?
Looks like they are sending malformed SIP packets. “61605branch=z9hG4bK16124a21”, looks like it should have had a “;”, at least, between the port number and the branch parameter.
In that case it is so badly broken that it needs to be fixed wherever the damage is occurring (which might be in your router, rather than at the ITSP).
Note this forurm is not appropriate for questions on configuring AsteriskNow and the correct forum will depend on whether it is FreePBX or “Asterisk GUI” based. In the former case, you should use freepbx.org/.
You should probably run with sip set debug on, or get a wireshark capture, to find out exactly what is in the broken SIP request.
Just to be clear. Asterisk is not objecting to the host name. It is objecting to the service name. It would normally expect to see something like 5060, although any natural number up to 32768, except 0, would be sort of acceptable, but the code also seems prepared to see a service name, like “sip”. Using a name is probably not actually allowed by the SIP protocol.
Because there is a delimiter missing, after the port number, it is treating the combination of the port number and the following parameter as a name, and trying to look that up.
Because that is totally invalid, and because it is not using the default (5060) port number, it is not really sensible to try and work round the problem. You need to fix it at source.