This comes from G.711 audio codec PCM procedure.
G.711 defines two logarithmic codecs used for PCM (Pulse Code Modulation) audio data: a-law and u-law. Codec algorithms are based on the perceptual properties of the human ear - weak signals are masked by strong ones.
After compression (from 14 bit sample in u-law and 13 bit sample in a-law) to 8 bits, the ...
check this line in sip.conf :
canreinvite = no ; allow RTP voice traffic to bypass Asterisk
if it set to yes RTP traffic will _try_ to go directly between SIP endpoints.
If it set to no - all traffic will be sent over PBX.
The default nmap options only scan for TCP services (and even then only the top 1000 most common ports).
UDP portscanning is more difficult and therefore not done by default.
Please take a look at for instance the nmap manual for more detail on UDP scanning: https://nmap.org/book/scan-methods-udp-scan.html
I've used SRTP with Asterisk before without requiring a client certificate, but as pointed out, this allows you to control access based on the issuer of the certificate and guarantee the source of the SIP request.
This allows you to validate that the phone is setup by you, and not just some random who found your SIP server. Just like a server presenting a ...
Finally figured out the solution after spending an entire day. This is what happens when you copy the configuration from the internet!
Anyways the problem was that on my sip.conf I had
doing a google search on insecure=port yields:
insecure=port ; Allow matching of peer by IP address without matching port number
That explains why ...
Finally figured this out! TLDR: disable power management on the host.
Despite the low CPU usage, we still figured this was something to do with CPU load. So, we were experimenting with loading down the CPU, expecting this problem with the dead spots in the calls to get worse. Instead, it went away completely. So, after looking at CPU usage stats in vCenter ...
The most accurate VoIP QoS metrics you have are measured by your VoIP endpoints.
You can intercept transparently all RTCP traffic between the VoIP endpoints on your routers, then parse the RTCP packets – see RFC 3611, RFC 7266.
It depends. If you do any transcoding (in other words the two endpoints use different codecs) then Asterisk will definately be in the RTP stream. If your two endpoints are on opposite sides of NAT, then Asterisk will likely be in the RTP stream (also depending on reinvite settings). If both endpoints are on the same side of NAT then likely no.
One-way audio with SIP/RTP calls is caused by one of the pair of RTP streams not being established. This is either a routing (i.e. NAT) problem, or a firewall problem. By default, SIP usually causes RTP streams to be established over UDP with destination ports on either side between either 10000-20000, or 16384-32768. Both sides must be able to make an ...
The Freeswitch Wiki gives several tips, including reducing RX and TX buffers to avoid bufferbloat, and tring different TCP congestion control algorithms.
Over at protocols.com there are a lot of good general tips, and the thing you can probably do the most is send larger packets less often to reduce overhead.
I don't know much about RTP, but if you are ...
You can always change the conditions that will trigger an inspection.
To do so, you need to create a class-map and a policy-map.
First go in your configuration terminal and create the class-map;
asa(config)# class-map SIP_5080
asa(config-cmap)# match port tcp eq 5080
Then create a policy-map;
asa(config)# policy-map SIP_Policy
after a few dozen of customers, you will find it expensive and difficult to maintain all those servers. FreeSWITCH supports multi-tenant scenarios, where you can have multiple subscriber domains and independent dialplan contexts. In general, I would advise to use FreeSWITCH instead of Asterisk for all green-field projects.