Hello,
I am newbie to this field. We are trying to use a separate card for handling the rtp voice traffic but use the RTPProxy (IPtel) software to handle the NAT issues. We have been fairly successful in doing that.
The problem now is to handle asymmetric NATs. I hear one way audio.We are not sure how to handle this when there is one machine running rtpproxy software and another card with a different IP handling the SDP (In nathelper.c of Openser new_ip= card IP). In the symmetric NAT scenario this works fine. I would appreciate and pointers to modify rtpproxy for this configuration.
We use rtpproxy 0.3, Opneser 1.1.0.
-the card only handles RTP data and has its own GbE port
- made changes to nathelper.c nathelper.cfg source code to account for separate IP addrs
- made changes to RTPProxy to open channels for RTPtraffic flow on the card.
-Openser,RTPProxy and the card , all 3 different Public IPs
Thanks
Nithin
Nithin Rajagopal nrajagopal@signalogic.com wrote:
I am newbie to this field. We are trying to use a separate card for handling the rtp voice traffic but use the RTPProxy (IPtel) software to handle the NAT issues. We have been fairly successful in doing that. The problem now is to handle asymmetric NATs. I hear one way audio.
What do you mean as "asymmmetric NAT"? Cone NAT or asymmetric RTP client behind NAT?
We are not sure how to handle this when there is one machine running rtpproxy software and another card with a different IP handling the SDP (In nathelper.c of Openser new_ip= card IP). In the symmetric NAT scenario this works fine. I would appreciate and pointers to modify rtpproxy for this configuration.
So I suppose you mean asymmetric client behind NAT, don't you? It's more hard case. But if only signaling IP and IP for RTP differs, it's good. Problems (almost unavoidable) appear if client's source RTP address differs from destination RTP address (specified in SDP), "address" here means both host and port.
Valentin -
I am newbie to this field. We are trying to use a separate card for handling the rtp voice traffic but use the RTPProxy (IPtel) software to handle the NAT issues. We have been fairly successful in doing that. The problem now is to handle asymmetric NATs. I hear one way audio.
What do you mean as "asymmmetric NAT"? Cone NAT or asymmetric RTP client behind NAT?
The NAT uses one port to transmit to the outside world and receiveds on an other port during the call. This NAT (Linux router/gateway for the end point like an ATA or softphone) is at customer location. I gather from the customer that the the end point (client behind NAT) is symmetric w.r.t its RTP port (same port for tx and rx of the RTP stream).
We are not sure how to handle this when there is one machine running rtpproxy software and another card with a different IP handling the SDP (In nathelper.c of Openser new_ip= card IP). In the symmetric NAT scenario this works fine. I would appreciate and pointers to modify rtpproxy for this configuration.
So I suppose you mean asymmetric client behind NAT, don't you? It's more hard case. But if only signaling IP and IP for RTP differs, it's good.
The signaling IP and RTP IP are not the same.
Problems (almost unavoidable) appear if client's source RTP address differs from destination RTP address (specified in SDP), "address" here means both host and port.
The destination IP of the RTP channel opened in the card which works in conjunction with rtpproxy is the IP of the NAT router/gateway and source IP of the RTP stream coming into this card handling RTP stream is also that of the same router/gateway. But the ports are different. Do you think this is the problem?
Please note- We use rtpproxy 0.3, Opneser 1.1.0.
-the card only handles RTP data and has its own GbE port
- made changes to nathelper.c nathelper.cfg source code to account for separate IP addrs
- made changes to RTPProxy to open channels for RTPtraffic flow on the card.
-Openser,RTPProxy and the card , all 3 different Public IPs
Thank you for the response.
Regards Nithin
-
Nithin Rajagopal -
Valentin Nechayev