Re: [reSIProcate-users] confusion on STUN client

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

...inline...

On Sat, May 14, 2016 at 2:44 PM, Tom Chen <chentom60@xxxxxxxxxxx> wrote:

Hello,

Webpage https://www.resiprocate.org/STUN_support introduces a way to use UdpTransport class to get STUN mapped IP address and port.

m_pUdpTransport = (resip::UdpTransport*)mStack->addTransport(UDP, UDPPort, V4, StunEnabled, IPAddress));

UdpTransport includes two methods for STUN client support:

bool stunSendTest(const Tuple& dest);

bool stunResult(Tuple& mappedAddress); 

I am wondering whether the STUN client, m_pUdpTransport , can not only be used to interact with STUN server but also be used to transmit & receive media stream data to/from callee? 

[Scott]   You can use rutil/Stun.hxx and Stun.cxx in your own UDP socket class in much the same manner as UdpTransport if you like.  I don't think it makes sense to use UdpTransport itself though.   

My understanding of using STUN server to do NAT traversal during a Voip phone call is that, the STUN client selects a local port and creates a socket to bind to the local port and IP address. Then the STUN client contacts an external STUN server to get its STUN mapped public IP address and port. This public address and port are used in SDP portion of SIP INVITE message for remote peer to know where to send RTP media stream to the caller. Since the local port and IP address have been tied to STUN client socket already, they can not be used to bind another socket for local VOIP applications to send media stream to callee, thus, the application has to send / receive media steam through STUN client. Is this correct?

[Scott]  STUN doesn't work in all NAT traversal cases - this is the reason for the development of the ICE protocol.  There is discussion of this in the ICE RFC is you are interested:  https://tools.ietf.org/html/rfc5245

Some STUN client implementations just bind to an ephemeral port, collect the public IP/port and use this in the SDP - hoping that your public/IP port mapping don't change based on your source port.  In this case the RTP socket is bound to it's own source port.

If you need to send the STUN request from the same source port as the RTP sender, then you will need use something like the Stun.hxx class you mentioned above to help you send and parse STUN messages off your applications RTP port.    OR     The other option is the use the reTurn client API's, which may need a few adjustments (if you are not using the TURN logic).  If you use the reTURN API's and identify required changes, those can be submitted back using a GitHub pull request.

Thanks,

Scott

 

Tom

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/