Problem is that I have one user that has T-mobile’s home internet service as his ISP. His SIP client will register just fine, but he can neither place or receive calls. From searching the Internet I get the impression that this is not an uncommon issue with T-mobile, and in some cases system administrators have just given up and said if you use T-mobile there is nothing we can do. But on the other hand I have also seen it suggested that if the user can connect using a port other than 5060 it might work. Of course my other extensions and trunks use port 5060 so I can’t just change it system wide. I seem to recall that back when I was using CHAN_SIP there was a port setting for each extension, so you could set a custom SIP port for one extension if you needed to. But now that we are using PJSIP, I just can’t seem to find that setting. Is it no longer possible to set a custom SIP port for one extension only? And if it is possible, how do you do it?
Or is there another workaround for T-mobile users (neither I nor the user are networking gurus, so simple solutions are the best)?
It is chan_pjsip that allows a different Asterisk side port to be used for different extensions. The only port you can set per extension for chan_sip is that of the remote user, but, I presume that the remote user is registering, in which case the port number is taken from the registration, along with the address.
You can do it with chan_pjsip, by using more than one transport. I’m not sure if this can be done through the GUI, or whether you have to add the extra transport as a customisation, and reference it by literal configuration parameters for the extension.
Note that there are security arguments for moving everyone to a port that is totally unrelated to 5060, a long as your ITSP will accept this.
Sorry but I didn’t really understand much of that. The remote user is registering, but on port 5060, it is just that no communications are taking place thereafter. If you try to place a call to the user you hear ringing tone and then it goes to voicemail, but the user’s device never actually gets the call.
If registration works, then I suspect that using TLS will resolve the issue. If you’re not already using TLS then you’re free to set it to some random port number.
I missed that the registration worked. I don’t think this is about port numbers, but probably about dynamic NAT rules, e.g. a very short expiry or expiring after the first response.
Does the phone consider the registration successful. If not, there might not even by a short term dynamic NAT rule.
Thanks for your suggestion. I did set up another PJSIP transport using port 9060 but it did not work, in fact the endpoint wouldn’t even register. But in the process of trying to make it work the user mentioned that his client could do IAX. So I had him try setting up an IAX extension, and created an IAX extension in FreePBX, and very surprisingly that worked. TLS might work if I knew enough to set it up, but for now I’m going to leave it at IAX.
All I know is that this setup worked fine until he switched to T-Mobile and I have read other posts about this exact same issue with T-Mobile’s home internet service. I have no idea what dynamic NAT rules he may have on his end but we got an IAX extension working so for now that’s good enough.
I sent the user a message about SIP ALG, but I don’t know if he’ll know how to find the answer. If they do have it enabled then that will definitely kill SIP connections; I have never seen any case where enabling it doesn’t make things worse. Thanks for reminding me of this!
It appears that this is definitely a SIP ALG problem, a solution that is the easiest is to use TLS… All you have to do is make sure the VoIP phone has its certs up to date (maybe even install some), and enable TLS on your FreePBX. Another method is to use a reverse proxy that would allow ip address xxx.xxx.xxx.xxx to connect on port xxxx and proxy this to port 5060 on your freepbx (if that is the port you are using). Then have the phone connect to this proxy on the custom port… … … I think you get where this is going, its a lot of work so the best solution is probably to have this specific user use TLS (plus its a big upgrade anyway).