I subscribe to our ftth provider with internet package that comes with telephone landine via gpon ont.I bypass and bridge mode gpon ont and let my pfsense do the pppoe authentication .II then connect my yealink T2IP and it register and can make regular calls now i have setup freepbx on VM and everything is working flawlessly
I only have one issue that every time I call iPhone or IOS device only I get a message from my ISP(voip) that the phone is switch off or unavailable
I’m pretty sure something is wrong with my setting because I have try MicroSIP and everything is working fine
482 History-Info: <tel:+966559503340;Reason=SIP%3Bcause%3D503>;index=1,<tel:+966504004000>;index=1.1
I believe that the 503 is an internal SIP status “Service Unavailable”.
Can you please post a SIP trace for a successful call made directly from MicroSIP to the same number? Then, we can see what differences in the outgoing INVITE may have caused the rejection.
Mobile phones disable applications that are in long I/O waits, to save battery. On Android, you can selectively disable this, but for Apple ones (and best battery use on Android) you need to instruct a push server, that sends a signal to wake up the mobile application.
If you use Sangoma’s proprietary mobile phone VoIP phone, part of the service you get is the push server, but for other ones, you have to make your own arrangements, and, although I’ve no practical experience of this, someone has to pay for the service.
I believe with the Sangoma mobile phone app, you point FreePBX at a proxy they provide, which deals with the push operation.
You need to use a push service if you are using a VoIP application on an Apple device. As I already explained, the phone operating system will put the VoIP application to sleep, so it will not respond to incoming SIP and you need the push service to tell the OS to wake up the application.
This is a a fairly well known feature of Apple phones.
Also, as I said this applies, by default, to Android, but you can mark apps to never sleep, on Android.
dear david
i’m not talking about VoIP application in ios , It’s a regular phone call like VoLTE etc
and this issue only with iPhone (IOS) because I try to call an Android or Nokia or Motorola even very old phones with no internet and the calls just work fine I hope you got my point
I would say that was not an Asterisk/FreePBX issue. The only reason I can think of for selective failure of normal mobile calls to an Apple product would be that Apple have the caller ID on a blacklist (or maybe that caller ID was suppressed). I think the mobile network will destroy any other characteristics derived from the way the call was originated.
I assumed VoIP, because a normal mobile call is a normal mobile call, however originated.
This issue is getting quite interesting, because the INVITEs sent by MicroSIP and Asterisk are quite similar, yet only the Asterisk one results in a failure.
As I know nothing about the Saudi phone system, please confirm my assumption that the 055 mobile you are calling was issued by Saudi Telecom Company (you didn’t port it elsewhere), and they also your trunking provider and ISP.
One thing that looks strange is that Asterisk is presenting ulaw as the first priority codec (both before and after removing g729 and g722), even though your screenshot clearly shows alaw on top. Possibly, try enabling alaw only and see what is presented.
Another detail is that MicroSIP is sending a Route header (generally undesirable). Conceivably, that makes a difference. Test by removing the \;hide from your Outbound Proxy and see whether non-iOS calls still work, and the Route header is now present.
If neither of these help, I’ll try to look at the differences in more detail.
also i can see this phone number +966504004000 in the logs (STC) Provides a service(mawjood) the purpose of this service is to notify the customer that someone tried to contact via call but to no avail in case of device unavailability or bad signal , I don’t know is that has anything to do with the issue
I think the server is trying to make two calls at the same time
I agree (so far) that we should be able to make this work, but I’m puzzled about several things.
The Wireshark capture of the successful call looks fine, but the failing capture has no communication with the trunk at all. Please explain (PBX has two NICs and you were only capturing on one, capture file was filtered, capture was taken other than on the PBX, etc.)
Please explain the 22.5.26.182 IP address. It looks like a public IP, but it is assigned to US DOD who are presumably using it only internally, as it is not routable on the global internet. Is this something routed within STC, or are they using it only as private addresses, similar to 10.x.x.x? If there is NAT involved, describe the devices, including make/model.
That’s certainly a possibility – the second call would indeed be routed to an error announcement, though I’d expect a 486 or 603 status, not 503. And, we still need to understand why this only occurs when Asterisk is in the path. Does anything appear or get logged on the iPhone for the attempted call?
I don’t understand at all. What is the ‘original gateway’? Is this something still in the path of either the direct MicroSIP call, or the attempt through Asterisk? Or is it just a third way to make calls on the STC trunk?
