Share via

Client Application Behind a NAT (Windows Embedded CE 6.0)

  • Article

1/6/2010

In the scenario represented by the following steps, the client is behind a NAT that does not support the Universal Plug and Play (UPnP) Internet Gateway Device (IGD) device control profile (DCP). The client initiates a PC-phone session, using an Internet Telephony Service Provider (ITSP), with a gateway that is not situated behind a NAT.

  1. The client application creates a Session object for a PC-phone session using IRTCClient::CreateSession.

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

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

  4. The RTC Client API calls the provided IRTCPortManager methods to retrieve the external IP address and port pairs on the NAT and the internal port and address on the client machine. It uses these port and address pairs for the audio streams on the PC-phone session.

  5. The RTC Client API uses the internal IP address on the client and the external IP address on the NAT to initiate the session. It transmits the external address and port on the NAT 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 for a client located at 1234567@microsoft.com. The Session Description Protocol (SDP) message in the SIP message body contains the external IP address (5.6.7.8) and port (5678) of the NAT.

    INVITE sip:1234567@microsoft.com;user-phone SIP/2.0
To: sip:1234567@microsoft.com;user=phone
From: sip:ClientA@microsoft.com
Call-ID: abcdefg
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: XXX
....
C=IN IP 5.6.7.8:5678

  6. If the RTC Client API receives a 200 OK response to the INVITE but discovers that the connection address in the received SDP message has changed from the address it sent, the RTC Client API calls IRTCPortManager::UpdateRemoteAddress; then, after the client responds with the corresponding ACK message, the media stream begins.

  7. Either party decides to terminate the session. The SIP BYE message is sent and the session is terminated.

  8. The RTC Client API calls IRTCPortManager::ReleaseMapping to inform the client application that the session has been terminated and the mappings the Port Manager is maintaining should be released.

See Also

Concepts

NAT Address Mapping