Consider server S with some public ip and client C behind NAT N. Now C sends some messages on a UDP channel to S. Client C declares the port to which S should connect the RTP stream. As you might have noticed its a standard voip problem where we can use ICE(STUN/TURN). However I am not clear about the flow. The problem is S can form a rtp stream with nat but then what port should it connect to? The only option is the port sent by C. But then does the client reserves that port on nat? Please also discuss symmetric nat case.
There are basically two options this could be handled by NAT.
First, the NAT implementation can use an Application Level Gateway for
RTP. In this case it will create a new entry in the NAPT mappings. In that mapping the client-facing port should be the one signaled, the server-facing port can be random. After the new mapping has been created, the ALG overwrites the port and ip in the RTP message with the server-facing data of that new mapping. This is transparent for clients, but NAT implementations need to keep up with the protocols.
Secondly, if supported by the NAT gateway, a client could use a protocol to learn it's server-facing ip and to allocate a port before signaling
RTP. Most common protocols to do this are
UPnP. This needs work/added complexity on the client side but is more generic as only the client needs to update it's protocol implementation and can use this for other protocols as well.
For RTP traffic common way to solve NAT is: server announce public ip and port for current call and just wait for first RTP packet arrived to this ip&port from client. after that server starts send RTP traffic to source ip and port of arrived packet (not to source ip|local| and port announced by NATed client)