Difference between revisions of "Our Architecture"
| Line 1: | Line 1: | ||
| − | + | [[image:whiteboard Fabio.jpg|550x356px]] | |
| + | |||
From [http://www.gnugk.org/gnugk-manual-5.html#proxy Gnugk website]: | From [http://www.gnugk.org/gnugk-manual-5.html#proxy Gnugk website]: | ||
Latest revision as of 15:52, 12 March 2007
From Gnugk website:
Call signaling messages may be passed in two ways. The first method is Direct Endpoint Call Signaling, in which case the call signaling messages are passed directly between the endpoints. The second method is Gatekeeper Routed Call Signaling. In this method, the call signaling messages are routed through the gatekeeper between the endpoints. The choice of which methods is used is made by the gatekeeper.
When Gatekeeper Routed call signaling is used, the gatekeeper may choose whether to route the H.245 control channel and logical channels.
Case 0 The gatekeeper isn't present. The H225 protocol isn't used; instead the H323 terminals need to know each other explicitly (i.e. by means of ip address and port). The H.245 control channel and logical channels are established directly between the endpoints.
Case I The gatekeeper doesn't route them. The H.245 control channel and logical channels are established directly between the endpoints.
Case II The H.245 control channel is routed between the endpoints through the gatekeeper, while the logical channels are established directly between the endpoints.
Case III The gatekeeper routes the H.245 control channel, as well as all logical channels, including RTP/RTCP for audio and video, and T.120 channel for data. In this case, no traffic is passed directly between the endpoints. This is usually called an H.323 Proxy, which can be regarded as an H.323-H.323 gateway.
To make H323 -> SIP calls we are interested in Case III. We haven't accomplished anything in this area (yet).
