A bridged network essentially makes the VM its own computer on the network without the need for the host OS to manage any services or routing. If you use a NAT, the IP of the host is exposed, but the internal NATted IP of the VM is hidden from the network. Outbound traffic should work fine, but inbound (not response) traffic isn’t able to directly access the NATted IP without the host’s help.
In a bridged configuration, your host, for example (IPV4), could have the ip 10.0.0.2, and your VM could be 10.0.0.3. From the network, you can route traffic to 10.0.0.3. The VM’s kernel modules know where to send that traffic.
In a NAT, the only exposed IP is 10.0.0.2. The VM’s ip could be 192.168.1.2 which is not directly accessible from the network. However, if the traffic is initiated from the VM, it will be tagged with both IPs, and the network and host will know how to route the traffic when it returns. If it’s initiated from the network, it must go to 10.0.0.2, and that host believes that the traffic was meant for it unless you’ve set up some mechanism for forwarding that traffic. This is why I suggested a router.
In the config I would use, the router’s internal ip would be 10.0.0.1 (the IP from ISP could be anything), the host is 10.0.0.2, and the bridged VM is 10.0.0.3. Within the router, you can say, “send all inbound SIP and RTP traffic to 10.0.0.3”, and the rest to 10.0.0.2 if you had the need to allow any other inbound traffic. This can be done by telling the router which ports to forward to the VM.
Here’s an example from a router…