On Asterisk 18 you may have to do what I mentioned earlier:
if using pjsip you must SSH/Telnet into FreePBX and at the command line /etc/asterisk you must add an entry for each extension in pjsip.endpoint_custom_post.conf as such:
[233](+)
force_rport=no
That does not seem to be the case anymore with newer Asterisk versions and these phones.
What is the softphone software that you are using on your PC and mobile phone?
There’s no chatting or negotiation for standard SIP processing. Each side picks one port number, from its range, without any knowledge of the range on the other side. There is no back and forth. Without early media. either the INVITE contains the caller’s port number, together with the 200 OK containing the callee’s number, or the 200 OK contains the callee’s, together with the ACK containing the caller’s. The latter, late offer, is only likely to be seen with Cisco equipment.
ICE, as typically used with WebRTC, provides a number of candidate address/port combinations, and the other side tries them until one that works is found, but the whole list is provided, and there is no real mutual agreement.
Note that voip.info hasn’t been maintained for a long time, and a lot of there was always wrong.
I don’t know how Asterisk handles an even number end to the range; it’s safer not to tempt it.
Hi Ted,
I’m using Linphone on my PC and mobile phone.
Kind regards,
Mr. Rüdiger
Yes. As I pointed out there was a bug in the provided config file on there. Sigh. That’s common with open source documentation I know from experience. But even the current defaults for the range in FreePBX 17 are wrong, according to voip.info, it’s link to it’s original source document which refers to Unix networking code, you, and Dicko. This is what happens when people blindly accept defaults without questioning them.
I’ve learned to be circumspect in citing as authoritative anything without qualifying it unless I can duplicate it myself. For example I can say authoritatively that the 7961G works on my setup with the other phones I cited and the version of FreePBX and Asterisk I cited and the config I cited. That can be tremendously helpful in troubleshooting because then the person with the problem knows that SOMEONE got it working - that it’s not a hopeless case. It’s just a matter of figuring out the config.
Keep in mind that all of us, and all our gear, are getting older - and the standards (like SIP) are NOT changing. Every day that passes there’s more devices running SIP in the world and the ones out there running SIP are getting older - yet the protocols are NOT changing. You can for example plug a vacuum cleaner into your wall outlet that was manufactured 100 years ago and it will still suck. The more vacuum cleaners there are in the world the less likely someone will come along and say “let’s change the standard that power is delivered with” because while there may be a slight engineering benefit, it will inconvenience enormous numbers of consumers. The same applies to SIP to Ethernet to countless other communications protocols.
What has to be guarded against with more complex communications protocols is people misunderstanding the “defacto standard” for using it and then changing that and breaking things. Which is, apparently, what has happened here.
I provided a link to the earlier document where the 16384/32767 range originated from. Regardless of whether you or I think that’s “right” the fact is that somewhere there’s a lot of pieces of gear that have that defacto limit. An Asterisk developer coming along later and just arbitrarily changing that to 10000-20000 just because they have a fetish for zeros or something - is just going to cause problems for people in border conditions who have that older kit.
You can do what you want - keep to the Asterisk default of 10000 to 20000 - but for me I am going to configure my phone to:
and configure my FreePBX system to a range of 16384 - 32767 and then I’m going to tell anyone else with a Cisco phone to do this and if the rest of the world wants to try to encourage people to use the incorrect range of 10000 to 20000 on their Asterisk server, then that’s their problem. They can deal with whatever border condition problems that they create for themselves by not bothering to dig into this. Clearly, the Asterisk developers already ran into this shooting themselves in the foot thing since they added code that silently extends the range to 20001 from 20000 to catch one of those border conditions. (at least according to voip.info they did which might be wrong who knows)
OK. Well I will dig into the Linphone thing since I have also used it successfully with a few test phones and it will be interesting to figure out why it’s not working with the 79x1 series of phones.
But I’d encourage you to try testing with the following other free clients:
Windows:
VoIP/SIP client (softphone) for Windows (tomeko.net)
MicroSIP - lightweight VoIP SIP softphone for Windows - Official Homepage
Bria Solo (formerly X-Lite) Download for Windows / Old Versions / FileHorse.com
(purportedly free, the current Bria version is decidedly not free but they offer a 30 day test, you might try it)
Download X-Lite 3.0 for Windows - OldVersion.com
(I can confirm x-lite 3 absolutely works even on windows 11 for audio and I frankly like the interface of the older xlite 3 better. Video is troublesome on it)
Android:
Voip By Antisip (+Video) - Apps on Google Play
(might not be free now I don’t know, take a look. I got it a long time ago)
SIPSKY : FREE VoIP Business Communication Solution APK for Android - Download (softonic.com)
(From India, must be sideloaded, latest Android may complain about it, I have not tested this one yet)
There’s no right range. the system sending the SDP chooses a port that it know it is safe to use at its side.
When you throw in NAT, there can be good reasons to restrict the range, as you might have several SIP user agents sharing a public address. I believe that having large ranges also causes problems with some virtualisation strategies.
And SIP does change. It’s changed between the original spec and the current one, and it has changed to cope with WebRTC, and NAT traversal.
I can’t find anything in the SDP RFC that constrains the port number used, other than the even odd rule, or says how the port number should be chosen. It’s a local implementation decision.
Good and NAT don’t belong in the same sentence let alone paragraph, LOL
For the 300 user network I am responsible for now, anyone who wants to use the PBX remotely is required to use a VPN with multifactor authentication. Once they are logged in they can run Cisco Jabber. I don’t allow outside access from the Internet to the PBX.
For my home play network, I run an IPSec VPN from my Android phone and Windows laptop if I want to make a call on my FreePBX system. It’s not MFA but I’m the only remote user on it so I am not worried.
I don’t see any good reason for a PBX to be directly accessible over the network from the general Internet. If you want to run SIP trunks into it then either you do it the Fortune 500 way where you get a static IP subnet, pick a number, do a 1:1 port forward, and setup a firewall rule in to restrict SIP to the trunk provider’s source IP, or you do it the cheap way and get a router with ALG or a firewall with decent NAT code that adds in dynamic pinholes. But the cheap way has always resulted in many posts on this forum (and others) with NAT problems so I can only conclude people are clueless and will never learn.
For the “I just want to have 1 remote phone in a warehouse” crowd, get a clue and fire up OpenWRT or dd-wrt on a router, setup an OpenSSL VPN that’s 24x7, route a subnet to it, and plug any phone you want into it and don’t crap up the phone’s config by trying to make the phone do a VPN to your VPN server.
Completely eliminates all the port or nat incompatibilities.
I realize my view is probably not that popular among the SOHO crowd. But, people, this is one area where the LargeOrg view is going to save you a ton of anguish and probably keep you from getting broken into. And I can’t think of much more that’s more attractive to the crackers than a PBX that they have pwned that has a trunk to the PSTN that allows long distance - and they hit the jackpot if it allows international calling on top of that…
My testing on my Pixel 6a:
Zoiper Beta - worked well
VoIP by Antisip - worked well
SIPSky - did not exit when closed on the phone - FreePBX showed the program still logged into the PBX. I don’t like Android programs that ignore user commands to exit so I deleted it
Linphone - echo cancellation did not work and program went into an audio feedback loop when recieving a call and just got worse and worse and worse so I deleted it. Also while I was getting audio from the phone to linphone, I was not getting it from linphone to the phone.
Note that your config is specifying a codec of g711a which although common in Europe and widely supported, may not be supported by this phone so the phone may be ignoring that configuration directive and merely using g711u. If you have modified codec selection in your Linphone to disallow g711u, that may be a problem. Unfortunately the Cisco datasheets for the 7941G/7961G seem unavailable so you may have to experiment to figure out if this phone does support g711a
I have not tested with Windows softphones.
It became a thing because Asterisk and eventually others have used that range as their default range. The 16384-32767 range is a Cisco thing which is what was used in the write up from a random website that voip-info.org linked to.
Neither IANA or the RTP RFC have any official port ranges for RTP. RTP can use any of the ephemeral ports from 1024-65535. Different vendors will have different port ranges they use for RTP communications on their devices.
Yealink - 11780-11800
Grandstream - 5004 (increments as needed) but accepts 1024-65535 as acceptable range.
Poly/Polycom - 2222 (increments as needed)
Snom - 18000 (increments as needed)
Freeswitch - 10000-50000
Cisco SPAs - 30000-50000
Cisco Devices - 16384 - 32767, however UCM only uses 24576-32767
Kamailio RTP Engine - 30000-40000
Kamailio RTP Proxy - 35000-60000
So trying to bang your head to figure out why Asterisk isn’t using “official” (when there are none) RTP ports is pointless. Because the range is basically as wide as the ephemeral port range and its vendors choice when picking their desired RTP range for their devices.
So we can all agree that offering a non mod 2 range and forwarding exactly that range back though the firewall is just plain wrong, advising anyone to use a drastically reduced range of 7 demonstrates lack of understanding that was not helpful to the OP, that’s just why I posted 
No it is not a Cisco thing. The VoIP page links to the source and you can go to the source document and see that is predates Cisco VoIP by a long shot and in fact the documents author explicitly states it came out of “the unix multicast code” He doesn’t say what Unix version but since he doesn’t say Linux it was probably 386BSD or the original Berkeley 4.3 BSD sources.
Cisco’s devs probably just read the same document that voip-info.org and thought “okey dokey let’s use that as a default”
I have tested with the following devices in my test bin: Yealink, Grandstream, Polycom, Snom, Cisco/Linksys SPA, Cisco Enterprise phones, Cisco IOS on it’s router, RCA (yes, Virginia Radio Corporation of America actually did produce a VoIP desk telephone and it’s as a sheetshow as you can imagine) as well as a number of TAs, Android-based softphones and desktop-based softphones.
All have "worked’ with each other and in no case have I had to muck around with changing the RDP port defaults in any device. In many cases, you can’t anyway.
In fact to add to your list: The VoIP by antisip Android softphone defaults to 40100 - 40180 (yes, by default they set the second number to an even number) and that’s the one that works better than the linphone softphone the OP was using and that I recommended he look into.
So all I can conclude is that the various “rtp port definition” settings available in Asterisk and in phones - DO NOT act as “filters” by restricting the device to only accept RTP on ports in that range, but rather act as directives telling the device what port to attempt to use when it issues an INVITE. Unfortunately, as we don’t have sourcecode access to the firmware used on those phones or the code in the softphones, this is one of those things that we can only logically deduce.
Because, otherwise, if the RTP port setting DID act as a “filter” and block incoming RTP outside of those ranges, then I would not be able to get audio originating on port 40100 to work with a phone that is configured without that range or with asterisk that doesn’t use that range.
Which means that it is almost for certain that any issue with a device not talking to another device when it’s just routers or whatever in between them - is NEVER going to be an “rtp port blocking issue”
That is ONLY going to come up when you have a NAT in between the PBX and the phone. And, logically, port forwarding any large swath of ports through a firewall is just plain wrong, even if it’s not drastically reduced, and is mod 2 and all that - basically defeats the purpose of a firewall, at least for the device you are forwarding to. Really, the only correct way to handle the issue is use a NAT that is SIP-aware, AKA ALG - and hope that the developers who wrote the ALG code were aware of how whatever phone you are using behaves.
Except that I didn’t advise doing that, I said that voip-info did and speculated that possibly the phone’s directives WERE limiting the incoming rtp range but that I’d test that. And after testing, it’s clear they don’t.
However I don’t have a huge amount of sympathy for the OP being confused by hijacking this to dive into RTP - he didn’t provide a writeup of his environment and in some cases I had to ask multiple times for information before getting it. He started out with 2 problems - phone registration - and phone connectivity to the softphones he’s using - and clearly jumped to conclusions that “linphone is doing it right and the Cisco 7941G was broken in some manner” once he got the 7941G registered.
When in reality, I’ve NOT been able to duplicate his problem with other phones and other softphones communicating to the 7961G (which uses the same code) EXCEPT when using linphone.
And further Googling shows a LOT of people complaining about linphone being broken in other environments in the past.
Linphone’s code is OSS:
So my recommendation is either diagnose the problem and submit a patch, or at least submit a bug (although they likely will want SIP traces) or use something other than linphone.
My apologies, I must have misread
and assumed that that was your advice 
That’s why I had double-quoted it - it was a quote from the weblink I cited. I was still trying to figure out what “startMediaPort” and “stopMediaPort” were doing to the phone.
Unfortunately, the documentation on these phone’s XML files is buried in the Cisco application developers guide and the current versions of that, document the XML files that the current phone firmware uses - which contain far more directives than the older phones (like the 7941/7961G) use. Sometimes you can use newer directives, and the phones silently ignore them, other times the newer directives cause the XML parser in the older phone to crash and the phone is left half-provisioned.
This particular model was very much a “transition” model for Cisco and even the newer Cisco firmware for the phone allows more directives so it’s quite possible to take an XML config file from one of this model running say version 9.2 that works, and then have it fail if 8.5 firmware is run on the phone. Cisco’s UCM web provisioner and device packs sort all of that rubbish out when someone is provisioning a phone - but when provisioning by hand you have to do some experimentation.
There is no problem in getting them to work together with non-overlapping ranges, as each side is responsible for selecting a port in its own range. I think you are re-introducing the misunderstanding that the ports have to be in the ranges for both. That’s basically impossible to achieve in the one round exchange used for SIP, as the range isn’t transmitted, and can only be determined, statistically over large numbers of calls.
That is exactly what I am trying to address.
There is very very little documentation out there that is easily accessible that basically states exactly what you just said. In fact, earlier you said:
" It is the range of port numbers, on the machine running Asterisk, on which it can choose to receive RTP from the peer. As symmetric media is used, the selected port number is also used as the source port for media going to the peer. The peer can choose any valid and free even port number as that on which it wants to receive media from Asterisk (or when direct media is used, from the other party)."
I don’t think you see how confusing this is because your last post here is essentially saying the opposite. I’ve really NOT been able to find much useful on rtp and most documentation basically says something along the line of “don’t worry about it, it will take care of it by itself”
As I said before, it is apparent that the 10000-20000 range in Asterisk config is only used to limit an rtp origination port, just as the 16384-32767, the 10000-50000 and the other ranges discussed are - that the reception port on the device is always going to be something within 1024-65535 In other words, the receiver isn’t blocking things outside of it’s configured rtp port range.
These configs only have meaning when working with port forwards through a NAT or firewall that does not have the ability to look at the SIP header.
Now if anything in what I’ve posted above is incorrect, then please explain it.
It only limits the port used on the Asterisk machine, but as Asterisk uses symmetric media, that is both the transmission and reception port on that machine.
But then the reception port must be negotiated during the SIP handshake, correct?
no, rtcp port will always be rtp port++, it is part of the protocol, not negotiated.
NO Dicko, I wasn’t talking about the rtcp port.
Please refer to the following:
User Datagram Protocol - Wikipedia
“… The UDP datagram header consists of 4 fields, each of which is 2 bytes (16 bits):[3]… Source port number
This field identifies the sender’s port, when used, and should be assumed to be the port to reply to if needed. If not used, it should be zero. If the source host is the client, the port number is likely to be an ephemeral port. If the source host is the server, the port number is likely to be a well-known port number from 0 to 1023.[6]
Destination port number
This field identifies the receiver’s port and is required…”
So, in rtp (not rtcp) the reception port - that is the destination port - the port that is used by the receiving peer - I am assuming THAT is negotiated in SIP?
Note the following:
RTP: Some Frequently Asked Questions about RTP (columbia.edu)
" Each side in a bidirectional RTP session assigns their source ports independently, i.e., there is no assumption that if Alice sends audio to Bob on port 5000 (and RTCP on 5001), Alice also has to receive audio on port 5000. (Imposing such a restriction on ports would make it difficult for a host to participate in several independent RTP sessions using different tools.) Each side in a unicast session simply indicates to the other side where it wants to receive RTP packets, e.g., using SDP."
So, for example:
The 7941G phone is configured to use a rtp port of 16384-32766, Asterisk is configured to use a range of 10000-20000
Therefore, after call setup, the UDP packets in the rtp datastream that originate from Asterisk will have a source port of anything in between 10000-20000 and a destination port of 16384-32766, the UDP packets in the rtp datastream that originate from the 7941G will have a source port of anything in between 16384-32766 and a destination port of 10000-20000, the UDP packets in the rtcp datastream that originate from Asterisk will have a source port of 10001-20001 and a destination port of 16385-32767, the UDP packets in the rtcp datastream that originate from the 7941G will have a source port of 16385-32767 and a destination port of 10001-20001
Asterisk therefore is ONLY using the 10000-20000 directive to control the SOURCE port in its rtp packets that it’s sending, the DESTINATION port in the packets it’s sending is negotiated by the phone and will be between 16384-32766
The phone therefore is ONLY using the 16384-32766 directive to control the SOURCE port in it’s rtp packets it’s sending, the DESTINATION port in the packets it’s sending is negotiated by Asterisk and will be between 10000-20000
Asterisk therefore is ONLY using the 10000-20000 directive (effectively 10001-20001 due to rtcp being +1) to control the SOURCE port in its rtcp packets that it’s sending, the DESTINATION port in the packets it’s sending is negotiated by the phone and will be between 16385-32767
The phone therefore is ONLY using the 16384-32766 directive (effectively 16385-32767 due to rtcp being +1) to control the SOURCE port in it’s rtcp packets it’s sending, the DESTINATION port in the packets it’s sending is negotiated by Asterisk and will be between 10001-20001
Asterisk being symmectric means that if it’s sending an rtp packet with a source port of say 10000 and an rtcp packet with a source port of 10001, it will have told the phone to send it rtp packets with destination ports of 10000 and rtcp packets with destination ports of 10001
I cannot find a detailed description of RTP protocol negotiation in SIP that describes this - but it is vitally important to know what’s going on if you are attempting to create large rtp port forward ranges in a NAT or firewall that isn’t dynamically inspecting the SIP rtp / rtcp packets and opening pinholes or dynamically forwarding them (the so-called ALG)