Re: [reSIProcate-users] confusion on STUN client

[Tom Chen <chentom60@xxxxxxxxxxx>]

Hi Scott,

Thank you for the reply.

I have some confusion in your reply:
1. "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."
I thought STUN/TURN are used for media streams to do NAT traversal as described in 5.2.1.1.1 of RFC6314: https://tools.ietf.org/html/rfc6314#page-28  . It details steps for RTP and RTCP streams to get public IP/port from STUN server and use them in SDP of INVITE message. If so, RTP socket has to bind to the same ephemeral port as STUN socket.

 2. "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."
Hmm, the UdpTransport class seems difficult to use in this scenario which is designed to process STUN &SIP messages not STUN & RTP messages. For example, the UdpTransport::processRxParse( ) function first checks if the incoming packet is STUN message, if not, then it checks if packet is SIP message, if not, then it deletes the packet buffer.

bool
UdpTransport::processRxParse(char *buffer, int len, Tuple& sender) {
. . . . .

// this must be a STUN request (or garbage)
   if (buffer[0] == 0 && buffer[1] == 1 && ipVersion() == V4)
   {
. . . . .
      bool ok = stunServerProcessMsg( buffer, len, // input buffer
                                      from,  // packet source
                                      secondary, // not used
                                      myAddr, // address to fill into response
                                      myAddr, // not used
                                      &resp, // stun response
                                      &dest, // where to send response
                                      &hmacPassword, // not used
                                      &changePort, // not used
                                      &changeIp, // not used
                                      false ); // logging

      return false;
   }

SipMessage* message = new SipMessage(this);
. . . . .
  if (!basicCheck(*message))
   {
      delete message; // cannot use it, so, punt on it...
      // basicCheck queued any response required
      message = 0;
      return origBufferConsumed;
   }
}

Could you answer me another question by the way? If I need to send media streams using TCP or SRTP stream, should I still use an UDP socket to communicate with STUN server to get public IP and port,  then create a separate TCP socket to bind to the same local ip & ephemeral port (that UDP socket bound) to send RTP, SRTP packets? ie, STUN & TCP/SRTP media stream use two sockets, one is UDP for STUN binding, another is TCP for media communication. I assume that if packets are from same local IP and port, then their public IP/port will be the same for most simple NATs no matter what socket type is, is this correct?

Thank you!

Tom

---

Date: Mon, 16 May 2016 14:05:50 -0400
Subject: Re: [reSIProcate-users] confusion on STUN client
From: sgodin@xxxxxxxxxxxxxxx
To: chentom60@xxxxxxxxxxx
CC: resiprocate-users@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/