Freeswitch kernel Study Notes (Continuous updates)

 

I have created a freeswitch kernel research and exchange group, 45211986. Welcome to join. In addition, we provide the SIP-based communication server and client solution.

 

It is relatively scattered. First, leave a footprint and add it slowly.

1.

Freeswitch extension numbers are stored in the conf/directory.
When the system starts, the extension information is loaded to the memory. When the registration package is received, USR under the directory is searched. The search is based on the to request for registration, the From header domain name is the system domain name,

Hierarchical Structure of the extension configuration file:

Domain
Groups
Group

USR

USR

Group
Groups
Domain

The directory contains several XML files. Each user can have an XML profile, which is dynamically loaded when the system starts,
In addition to file configuration, you can use the mod_xml_curl module to access the Web server.
Access the database to add a large number of extensions.

You can set some variables attached to the user in the user's configuration file.

The contents of the directory can be obtained by all modules of the system after being loaded to reduce data redundancy.

Dialplan global variables are accessed with $ {default_areacode} ", and channel variables are accessed with $ {default_areacode }"

The CONF/var. xml file defines the global variables of the system.

Configuration file template for a single user

<Include>
<User id = "1000"> // ID indicates the user name.
<Params>
<Param name = "password" value = "$ {default_password}"/>
</Params>
<Variables>
<Variable name = "toll_allow value =" domestic, international, local "/> // This variable is set for the user's channel and the user's Permissions
Her configurable variables:
Accountcode: User Account, which appears in CDR.
User_context: the user calls the value of "user_context" in dialplan.
Inclutive_caller_id_name: the user name displayed to the other user when calling (valid only when the called user is registered on the System)
Effective_caller_id_number: the user ID displayed to the other party (valid only when the called name is registered on the System)
Outbound_caller_id_name: the user name that is sent to the other party through the SIP Relay
Outbound_caller_id_number: the user number that is sent to the other party through the SIP relay.
Callgroup: Additional attributes,

</Variables>
</User>
</Include>

The default extension configuration includes:
A username for SIP and for authorization
A voicemail password
A means of allowing/restricting dialling
A means of handling caller ID being sent out
Several arbitrary variables that can be used or ignored as needed

Configure an extension process:

#> Cd/usr/local/freeswitch/CONF/directory/Default
#> CP 1000.xml 1030.xml

Replace all occurrences of "1000" with "1030"

Modify default dialplan

Reload the configuration file to make the configuration take effect:

Reloadxml

On the console, check which extension masters have been registered:

Sofia status profile internal

The dialplan of freeswitch has a separate directory. The conext of the extension is the conext. xml under the dialplan directory.

External links:

Freeswitch contacts the external world through the SIP gateway. freeswitch is a user on the SIP server.

Gateway configuration method:
Create a relay file:

Conf/sip_profiles/external/test. xml

<Include>
<Gateway name = "Custom">
<Param name = "username" value = "my_user_name"/> // user name and password provided by the SIP provider
<Param name = "password" value = "my_password"/>
<Param name = "Realm" value = "iptel.org"/>
<! -- Iptel.org requires a 'proxy' parameter -->
<Param name = "proxy" value = "sip.iptel.org"/>
</Gateway> -->
</Include>

Make the configuration take effect:
CLI execution:
Sofia profile external restart reloadxml (this command will kill the extension being called. The safer way is to use Sofia profile external rescan reloadxml)
Run Sofia status in CLI
Return System sip configuration information
There are two main types: 1. Gateway 2. Locally registered user (profile)

Mod_xml_curl:

This module is similar to the asterisk realtime mechanism. This module allows freeswitch to dynamically access external databases or Web servers when needed. This allows freeswitch core to be dynamically controlled.

For example, you can configure the extension in the database. freeswitch uses this module to load the extension.
You can bind the following modules:
1. dialplan
 
<Param name = "gateway-URL" value = "http: // localhost: 8080" bindings = "dialplan"/>

The system first accesses 8080 for each call.

.....

2. Configuration File

Sofia. conf file:

Global_settings node:
Subnode:
Log-level
Tracelevel
Debug-Presence
Debug-SLA
Auto-Restart
Rewrite-multicasted-FS-Path
To_host
Original_server_host
Original_hostname

Profiles node: CONF/sip_profiles/*. xml
By default, there are two
Internalx. ml
External. xml

Freeswitch high-performance technical features: Memory Pool, task queue, event driven, multithread, hash, state machine, memory pool, multithreading, task queue, event-driven, hash, and state machine.

Kernel startup process:

Two Functions
Switch_core_init initializes the core.
Apr_initialize (),
Switch_core_session_init,
Switch_core_hash_init,
Switch_console_init,
Switch_event_init,
Switch_xml_init,
Switch_log_init,
Switch_core_state_machine_init
Switch_scheduler_task_thread_start
Switch_nat_late_init,

Switch_rtp_init,

Switch_loadable_module_init initializes each module.

Call process: Incoming call
The SIP protocol stack receives the SIP Message from the transport layer and finally transfers it to the sipua layer to enter sofia_event_callback-> sofia_queue_message

Sofia_msg_thread_start-> sofia_msg_thread_run->
Sofia_process_dispatch_event -----------------
-> Our_sofia_event_callback-> sofia_handle_sip_ I _invite-> switch_core_session_request

Switch_core_session_thread_launch-> switch_core_session_thread_launch ---> switch_ivr_originate ()

Other: FIFO, conferrance, switch_ivr_originate
Enterprise_originate_thread-> switch_ivr_originate ---- switch_core_session_outgoing_channel ----> sofia_outgoing_channel-> switch_core_session_request->

Freeswitch kernel concepts: Session, channle, tec_private, event,
The core uses a finite state machine to manage the callback corresponding to each State in the call process.

After a call enters the system, a channel is established. The channle is a session maintained by the server. The core uses the state machine to schedule the session to transfer events.
A typical call flow uac1-uas, uas-uac2, uac1-bridge-uac2, call into the system, the system sets up session after starting switch_core_session_thread_launch thread continuously listens to session status, according to the status call the corresponding callback, of course, the state machine is finite, and the freeswitch state machine is divided into the following States:
On_init,
On_routing,
On_execute,
On_hangup,
On_exchange_media
On_soft_execute,
On_consume_media,
On_hibernate,
On_reset,
On_park,
On_reporting,
On_destroy.
The actual call process is in these statuses.

Uac1-uas: Incoming system, system build session:

Sofia_handle_sip_ I _invite-> switch_core_session_request-> switch_core_session_thread_launch,
After parsing the request, go to cs_new-> cs_init. After initialization, go to dialplan: cs_init-> cs_routing. The state machine calls back switch_core_standard_on_routing to find dialplan.
The system searches for the dialplan corresponding to the called sip settings and loads it To the memory,
Call status conversion: cs_routing-> cs_execut. The state machine calls switch_core_standard_on_execute and executes the loaded dialplan one by one according to the rule. This is the embodiment of programmable SoftSwitch, flexibly control the service provided to a call as needed. When the bridge action is executed, the system calls uac2, calls switch_ivr_originate, and creates the session, channel, and,
Finally, start the state machine thread switch_core_session_thread_launch to enter the state machine mode. cs_new-> cs_init-> cs_routing-> cs_consume_media,

USC2 finally responds to the 200 OK message body. The server negotiates with the SDP provided by uac1 Based on the 200 OK sdp message body. After successful verification, the server sends the 200 OK message to uac1, and the call bridging is successful. Uac2 state machine converts cs_consume_media-> cs_exchange_media, and media stream bridging starts.

State Machine transfer node:

/*!  \enum switch_channel_state_t  \brief Channel States (these are the defaults, CS_SOFT_EXECUTE, CS_EXCHANGE_MEDIA, and CS_CONSUME_MEDIA             are often overridden by specific apps)<pre>CS_NEW       - Channel is newly created.CS_INIT      - Channel has been initilized.CS_ROUTING   - Channel is looking for an extension to execute.CS_SOFT_EXECUTE  - Channel is ready to execute from 3rd party control.CS_EXECUTE   - Channel is executing it's dialplan.CS_EXCHANGE_MEDIA  - Channel is exchanging media with another channel.CS_PARK      - Channel is accepting media awaiting commands.CS_CONSUME_MEDIA         - Channel is consuming all media and dropping it.CS_HIBERNATE - Channel is in a sleep state.CS_RESET      - Channel is in a reset state.CS_HANGUP    - Channel is flagged for hangup and ready to end.CS_REPORTING - Channel is ready to collect call detail.CS_DESTROY      - Channel is ready to be destroyed and out of the state machine</pre> */