If you want to know some pre-history on how GTalk2VoIP service was created, please read article
The GTalk2VoIP gateway can be logically devided into two separate and/or independent parts: 1) VoIP gatewaying core and 2) Finite State Machine. What are they and how do they interact to each other to accomplish required effect we will try to briefly describe here. The figure below is also provided to ease the explaination.
1. VoIP Gatewaying core.
The Core in essence is our own implementation of a VoIP soft-switch. It consists of a number of VoIP signal processing stacks, like: H.323, SIP (including Yahoo's and Microsoft's perverted "dialects") and Jingle Audio of course. It also includes media codecs, transcoders and conferencing rooms (the last are just a subtype of transcoders).
Signalling stacks can initiate and receive VoIP connetions from a TCP/IP network (which Internet is) and produce a number of operational events to upper level - to Finite State Machine. Signalling stacks can be connected to each others using conference rooms or transcoders, so media streams from one type of stack can go through another, thus implementing a VoIP gatewaying between different type of VoIP networks. Control over signalling stacks interconnections is driven by operational commands which are generated by FSM. Transcoders also do conversions of voice compression algorithms (media codecs) used in voip networks.
For example, when GTalk user is talking to SIP user, media data from GTalk are usually encoded by iLBC codecs. These data are getting decoded by transceder into linear PCM16 format then encoded back into G.726 or GSM format (codec).
2. Finite State Machine.Finite State Machine (also can be refered as Sinite Automatoc) is a very important part of any PBX or a soft-switch. FMS is a logical machine, the commonly used technology, aimed to handle a large number of events and to control states of some operational objects. FSMs usually can be configured by a set of rules and procedures (predicative logic).
In terms of GTalk2VoIP gateway, the FSM is used to handle a numerous calls states and to control call processing objects (H.323 and SIP stacks) by generating control commands. When a call from GTalk arrives, a Jingle Audio stack emmits an INCOMING_CALL event to FSM. The Machine, according to configuration rules loaded into it, then generates ACCEPT command to Jingle Audio stack, and CALL commant to SIP stack (or H.323 stack, depending on how call must be treated). When CALL command initiated, another event comes to FSM, this time it indicates call progress state. The process continues till the call ends.
Finite State Machine also handles incoming messages from GTalk users and threat them like commands to execute. When you type CALL message, the Machine initiates a call to your GTalk using Jingle Audio and do the rest stuff.
If you are interested in our technology, have any ideas on extending it or use for your own products or services, please contact us to .