I would like to describe the current setup of my asterisk server ,
First I have a soft-switch which is used to provide a SIP Trunk to asterisk server , and the soft-switch redirect certain calls to the SIP Trunk i.e : 1700* numbers , and there the asterisk server has inbound routes , where I check the phone and redirect the call with the real number using Misc-Destination
and I am using a sub-range of RTP ports in order to make sure that we don’t encounter one way audio
some times the voice between A-party and B-party might lose the voice from the other party [while the call is in-progress] , so what I would like to know is there anything that I need to configure to get rid of this issue,
if any more data or description is needed let me know
Echoes, on VoIP are an end to end issue. It is the phone (or PSTN gateway) that does the echo cancellation. Certain things, like loudspeaking phones, can be very difficult to successfully echo suppress, and the high latency of VoIP means that echoes are noticed.
Changes in echo, e.g. switching to and from handsfree are likely to upset echo cancellers.
I would look into the RTP port range on the soft-switch and Asterisk. Is the sub-rangedefined on both sides?
It sounds like the initial call is established using valid ports, with-in the defined port range. But a re-INVITEmay select another port, outside of the sub-range allowed on either side. This could be the cause of one-way audio during a call.
I hope you meant directmedia, as canreinvite was deprecated many years ago. Conflicts will be resolved in favour of the last one of the two that appears in the configuration.
Also note that neither of them stop re-invites. All they stop is Asterisk initiating a re-invite for the purposes of routing media directly. between endpoints. They don’t stop a peer initiating a re-invite and they don’t stop re-invites for other purposes.
I didn’t mention directmedia, which would complicate finding the source of the issue. Symptoms would include one-way audio for new calls too, not just during a call.
What is the sub-range of ports you decided to use, what is the range?
Reducing the RTP port range is a counter-intuitive way to prevent one-way audio. That’s how I create one-way audio issues for testing purposes.
As a rule of thumb, there should be a minimum of two (2) ports for every call-leg *max calls.
There are too many factors to consider, network, firewall, RTP port ranges, etc… The best way to identify the source of your issue, is by capturing the issue using tcpdump and analyzing the call.
@poing for the port range the soft-switch that I am using support from 16384 till 65536 ,. and I took from 17000 till 60000 , as for the tcpdump , I installed wireshark on the server and from there I can listen to the calls , and see how the rtp is handled nothing there , asterisk passes the audio as it receive it
If you can see both sides of the audio at the Asterisk, then you need to check traffic at other points in the network. Again, there are too many factors to consider.
I removed all the firewalls , and connected the server to the softswitch directly through routers,
and for now we are facing the same problem again and I check the packets of udp , and here is a sample of the output :
Udp:
3643061861 packets received
3881844 packets to unknown port received.
147113 packet receive errors
3580415320 packets sent
16575 receive buffer errors
1155 send buffer errors
any new ideas that we could use is highly appreciated ??
Those statistics are not particularly useful. The ones from rtcp debug will be rather more relevant.
My guess is that you are seeing the effects of losing a single packet from a fragmented datagram, but, ideally, the media streams will not have any fragmented ones.
Wireshark can also provide much more useful statistics, on jitter, etc.
I took some traces with wireshark and I noticed dropped packets and jitter , plus I can see the statistics of the call from the softswitch side , and there I have found about dropped packets percentage more than 14%
Frame type 2 is Voice, so ordinary media. The likely cause is that the OS rejected a socket write. For UDP that could be there was no valid route, or there was no buffer space because there was a backlog for transmission.
(TCP will exacerbate network problems for real time traffic, because it will delay everything after a lost packet, so, if using TCP, that would be part of your problem.)
Why does everyone assume there is a magic option that will fix symptoms, particularly when the cause is not fully understood, but appears to be infrastructure related.
you are right , but if you are in my shoes , you will think about a quick fix and ignore other things ,
as for the setup it is pretty simple , inbound routes , and according the called number the destination will be misc-destination where I change the number to another number [TollFree number is mapped to a real number ]
in the flow above the first invite comes with the following format [ 1700XXXXXX ]
and in the second a number [ 0XXXXXX ] is returned to the customer
new update to this issue , I had some help with tuning of the network , everything is well , but when we do apply settings from the Freepbx , the problem appears[packet-loss] ,
so I would appreciate the insight if anyone has encountered this issue that when doing apply settings for asterisk calls gets interrupted and packet loss
