I have an ARI application that answer a call, then call another SIP server (not Asterisk), and creates a mixing bridge between the calls. The problem is that the RTP ports used between the bridge and the other server are not correct, resulting in one way audio. Using wireshark we see that Asterisk send audio on the same port as it receives it from the other server, instead using a different port. When calling this other server directly from an extension, all works fine.
ARI itself does not influence or control the RTP ports. Can you clarify what you mean by using a different port? The source port will be different than the destination port.
When calling from an extension, we clearly see that asterisk uses one port to stream the RTP to the other server, and receives RTP on another. But when we connect the sides by a bridge, it seems asterisk sends RTP on the exact same port it receives it, instead of using another port. The result is that audio can be heard on the asterisk side but not on the other side.
Asterisk always sends from the same port that it is expecting media on. I’d suggest you provide an Asterisk console log and packet capture to show what is going on.
I attached two flow diagrams from wireshark showing the problem. The first is a correct flow, generated by the Dial command. The second is the bad one generated by the ARI bridge. Please note the port number of the RTP flowing from the other server (192.168.0.5) to my asterisk server (192.168.0.41) and back. In the good flow they are 17022 and 7916 respectively. On the bad flow they are both 17024.
So in the non-working case we are SENDING to the port on which we received traffic. The source port of Asterisk remains the same. What have you configured on the endpoint? The SDP would also be useful to see what has been negotiated and provided for media ports.
Most people actually prefer that reciprocal port numbers are used, although, without nat=comedia, Asterisk should honour the SDP, even if the inbound traffic conflicts.
