Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Tutorial: make H.323 call go through NAT

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #21898 Reply
    ksabc
    Guest

    Some NAT software like Sygate, WinProxy, IP_MASQ_NETMEETING, IP_MASQ_H323, ISA2K etc. allow H.323 VOIP call to go through when you make the call from private network to public internet, how does it work?

    Suppose EndPointA & EndPointB is NetMeeting or other H.323 Gateway, NATServer is Sygate or Linux IP_MASQ software:

    EndPointA NATServer EndpointB

    EndpintA : private ip = 192.168.0.8 ( Set its gateway ip to 192.168.0.1 )

    NATServer : private ip = 192.168.0.1
    public ip = 202.48.32.55

    EndpintB : public ip = 64.78.32.168

    Step1 : EndPointA ====TCP Port:1720=== EndPointB with TCP SYN request to establish the H.225 connection ( for example source Port number= 35926 )
    EndPointA ====TCP Port:1720=== EndPointB with H.225 Q.931 SETUP message

    in the UUIE part, there have “sourceCallSignalAddress” field, include the EndPointA’s private ip address and a port number (35926), the NATServer will search the ip address + port number (192.168.0.5,35926) from the pure data area and replace the ip with its public ip address (some software will also replace the port number) and forward the package out;

    So the final “sourceCallSignalAddress: field is : Package[ip=192.168.0.8 port=35926] ===Change to==== Package[ip=202.48.32.55 port=35926] and send out

    Why need this step? because sometimes EndPointB will verify these values by comparing them to the TCP header;

    Also, NATServer will add the ip/port pair into its map table like doing with all other general applications to forward the incoming data from EndPointB back to the EndPointA;

    Step2 : EndPointA EndPointB with TCP SYN request to establish the H.245 connection ( for example source port number= 39980 )

    EndPointA ====TCP Port:1211==== EndPointB with H.245 Req TerminalCapabilitySet
    EndPointA ====TCP Port:1211==== EndPointB with H.245 Req MasterSlaveDetermination
    EndPointA EndPointB with H.245 Req TerminalCapabilitySetACK
    EndPointA ====TCP Port:1211==== EndPointB with H.245 Req MasterSlaveDeterminationACK
    EndPointA EndPointB with H.245 Req OpenLogicalChannel

    in the “mediaControlChannel unicaseAddress” field, include the EndPointA’s private ip address and the RTCP session port number ( for example 6431 ) which means the EndPointA will listen on UDP port 6431 for RTCP voice/video package and UDP port 6430 ( 6431-1 ) for RTP voice/video package; the NATServer will search the ip address (192.168.0.8) from the pure data area, get the port number used for the RTCP session ( same way: the port number field is just after the ip address field ), then replace the ip with its public ip address ( some software will also replace the port number ) and forward the package out;

    So the final “mediaControlChannel unicaseAddress” field is : Package[ip=192.168.0.8 port=6431] ===Change to==== Package[ip=202.48.32.55 port=6431] and send out;

    Also, NATServer will add the ip/port pair into its map table so the coming RTP/RTCP package from EndPointB can go throuth the NATServer and reach to EndPointA;

    Step7 : EndPointA EndPointB with H.245 Req OpenLogicalChannelACK

    in the “mediaChannel unicaseAddress” and “mediaControlChannel unicaseAddress” fields, include the EndPointA’s private ip address,RTP session port number (6430) and RTCP session port number (6431);
    same to Step6, NATServer will search the ip address(192.168.0.8), then replace the ip with its public ip address ( some software will also replace the RTP & RTCP port number ) and forward the package out;

    Step9 : EndPointA EndPointB
    EndPointA ===== RTCP Port:xxxx=====EndPointB EndPointA send voice/video to EndPointB

    EndPointA

    #21899 Reply
    Tom Howard
    Guest

    Thanks for a great explanation.

    As far as I can see, there is one problem with this approach. It doesn’t work well for incoming calls.

    If the NAT server doesn’t know that an H.323 client exists (ie. if there has not yet been an outbound call), then it doesn’t know where to forward the incoming Q931 SETUP message.

    Some NAT systems support H.323 in this way. Generally, _if_ they can support incoming calls, then it is only to one client.

    In my opinion, a gatekeeper is a better solution. It handles incoming calls much more elegantly by ringing all phones or one particular phone if it’s registered.

Viewing 2 posts - 1 through 2 (of 2 total)
Reply To: Tutorial: make H.323 call go through NAT
Your information:




<a href="" title="" rel="" target=""> <blockquote cite=""> <code> <pre class=""> <em> <strong> <del datetime="" cite=""> <ins datetime="" cite=""> <ul> <ol start=""> <li> <img src="" border="" alt="" height="" width="">