The Client Application is behind a NAT

  • Article

In this scenario, the client is situated behind a non-UPnP NAT. The client initiates a PC-phone session, via an ITSP, with a gateway that is not situated behind a NAT.

  1. The client application creates a session object for a PC-phone session with the IRTCClient::CreateSession method.

  2. The client application queries the Session object for the IRTCSessionPortManagement interface.

  3. The client application calls the IRTCSessionPortManagement::SetPortManager method to set the port manager interface for this session.

  4. The RTC Client API will call methods on the IRTCPortManager interface only if the application specifies this interface with the IRTCSessionPortManagement::SetPortManager method. The IRTCPortManager methods allow the RTC Client API to retrieve the external IP address and port pairs on the NAT, as well as the internal port and address on the client machine, from the client application. These port and address pairs are used for the audio streams on the PC-phone session. The client application should ensure that these ports and addresses remain open for the duration of the session.

  5. The internal IP address on the client and the external IP address on the NAT are used by the RTC Client API to initiate the session. The external address and port on the NAT are transmitted in the SIP INVITE message when a participant is added to the session. For example, the following SIP INVITE message header shows a client requesting a PC-phone session through an ITSP for a client located at 1234567@ITSP.com. The SDP of the SIP message body contains the external IP address (5.6.7.8) and Port (5678) of the NAT.

    INVITE sip:1234567@ITSP.com;user-phone SIP/2.0

    To: sip:1234567@ITSP.com;user=phone

    From: sip:ClientA@ITSP.com

    Call-ID: abcdefg

    CSeq: 1 INVITE

    Content-Type: application/sdp

    Content-Length: XXX

    ....

    C=IN IP 5.6.7.8:5678

  6. The application's port manager is responsible for ensuring that the NAT mapping is valid until the mapping is released.

  7. When the RTC Client API receives the 200 OK response to the INVITE and discovers that the connection address in the receiving SDP changes from the previous one, the RTC Client API calls IRTCPortManager::UpdateRemoteAddress. After the client responds with the corresponding ACK message, the media stream can begin.

  8. Either party can decide to terminate the session. The SIP BYE message is sent at this point and the session is terminated.

  9. The client application is responsible for releasing the NAT mappings once the session is terminated. The RTC Client API calls the IRTCPortManager::ReleaseMapping method to inform the client application that the session has been terminated and the mappings should be released.