Router not forwarding packets to other device through STUN mapped ports

Question

I have been implementing STUN in SIP protocol... I see that when I connect 2 devices behind the same NAT and enable STUN in both , I cannot receive media through the mapped ports..Is this behavior proper ??

I see that the router is not routing the media to the other device (present in same NAT) through the public side NAT... But both the devices do send media but CAN't RECEIVE any..

I have tried it with 3 routers and find that all the routers are NOT forwarding the packets to the other device.....

Is it a behaviour of Router NOT to route packets within the same NAT through mapped ports???

Answer 1

STUN is only intended to allow the client application to determine its public IP address so STUN by itself doesn't directly map any ports or affect media traversal through your NAT.

There are different types of NATs and they can cause havoc with your RTP (media) connections in different ways. There are a number of articles dealing with SIP and audio issues, here's one I wrote SIP and Audio.

If you are placing SIP calls to a SIP provider you are often better off not using STUN as the provider will normally have logic on their server that will replace any private IP addresses in the SP packets with the public IP address the SIP packet came from. And if the RTP packet arrives from a different socket than was advertised in the SDP portion of the SIP INVITE request the provider's media server will switch to that socket; this overcomes specifying a private IP address for the client's RTP socket.

If you are attempting to place a call between two SIP user agents both on private networks then STUN could be useful but you will probably need to set up port forwarding rules on the routers in front of both user agents.