Sofia
From FreeSWITCH Wiki
Contents |
Sofia Configuration Files, sofia.conf.xml
See Sofia Configuration Files.
Flushing/rebooting registered endpoints
You can flush a registration or reboot specific registered endpoint by issuing a flush_inbound_reg command from the console
fs> sofia profile <profile_name> flush_inbound_reg [<call_id>|<user@host>] [reboot]
If you leave out <call_id> and/or <user@host>, you will flush/reboot every registered endpoint on a profile.
Reloading profiles and gateways
You can reload a specific SIP profile by issuing a rescan/restart command from the console
fs> sofia profile <profile_name> [<rescan>|<restart>] reloadxml
The difference between rescan and restart is that rescan will just load new config and not stop FS from processing any more calls on a profile. Some config options like IP and port are not reloaded with rescan.
Deleting gateways
You can delete a specific gateway by issuing a killgw command from the console
fs> sofia profile <profile_name> killgw <gateway_name>
View SIP Registrations
You can view all the devices that have registered by running the following from the console
sofia status profile <profile name> FreeSWITCH>sofia status profile default FreeSWITCH>sofia status profile outbound
Debugging SOFIA SIP
The Sofia-SIP components can output various debugging information. The detail of the debugging output is determined by the debugging level. The level is usually module-specific and it can be modified by module-specific environment variable. There is also a default level for all modules, controlled by environment variable #SOFIA_DEBUG.
The environment variables controlling the logging and other debug output are as follows:
- #SOFIA_DEBUG Default debug level (0..9) - #NUA_DEBUG User Agent engine (<a href="nua/index.html">nua</a>) debug level (0..9) - #SOA_DEBUG SDP Offer/Answer engine (<a href="soa/index.html">soa</a>) debug level (0..9) - #NEA_DEBUG Event engine (<a href="nea/index.html">nea</a>) debug level (0..9) - #IPTSEC_DEBUG HTTP/SIP autentication module debug level (0..9) - #NTA_DEBUG Transaction engine debug level (0..9) - #TPORT_DEBUG Transport event debug level (0..9) - #TPORT_LOG If set, print out all parsed SIP messages on transport layer - #TPORT_DUMP Filename for dumping unparsed messages from transport - #SU_DEBUG <a href="nea/index.html">su</a> module debug level (0..9)
The defined debug output levels are:
- 0 SU_DEBUG_0() - fatal errors, panic - 1 SU_DEBUG_1() - critical errors, minimal progress at subsystem level - 2 SU_DEBUG_2() - non-critical errors - 3 SU_DEBUG_3() - warnings, progress messages - 5 SU_DEBUG_5() - signaling protocol actions (incoming packets, ...) - 7 SU_DEBUG_7() - media protocol actions (incoming packets, ...) - 9 SU_DEBUG_9() - entering/exiting functions, very verbatim progress
Sample Export
The following bash commands turn on all debugging levels.
export SOFIA_DEBUG=9 export NUA_DEBUG=9 export SOA_DEBUG=9 export NEA_DEBUG=9 export IPTSEC_DEBUG=9 export NTA_DEBUG=9 export TPORT_DEBUG=9 export TPORT_LOG=9 export TPORT_DUMP=/tmp/tport_sip.log export SU_DEBUG=9
To turn this debugging off again, you have to exit freeSWITCH and type unset. For example:
unset TPORT_LOG
ACL
You can restrict access by IP address for either REGISTERs or INVITEs (or both) by using the following options in the sofia profile.
<param name="apply-inbound-acl" value="<acl_list|cidr>"/> <param name="apply-register-acl" value="<acl_list|cidr>"/>
See Acl for other access controls
See acl.conf.xml for list configuration
Syntax
Call an extension on a Remote SIP Server
Basic form
sofia/<profile>/<extension>@<remoteserver>
Example 1:
sofia/$${profile}/$1/@example.org
Example 2:
sofia/foo/0@sipphone.com
where <profile> is the name of one of the profiles defined in sofia.conf.xml. By default, there is one profile defined as name="$${domain}", where the $${domain} variable is defined in freeswitch.xml, and defaults to mydomain.com.
Therefore, if you have not changed these config files and are dialing an extension on a remote server, the config would be
sofia/mydomain.com/<extension>@<remoteserver>
To list all profiles defined, type sofia status on the CLI.
Call a locally registered endpoint
Basic form:
sofia/<profile>/<extension>%<localserver>
Example 1:
sofia/$${profile}/$1%$${domain}
Example 2:
sofia/foo/101%192.168.1.1
where foo is the SIP profile, 101 is the userid of the registered endpoint, and 192.168.1.1 is the IP address of freeswitch.
If your SIP profile name is set to your domain, or the domain attribute is set in the profile (e.g., <profile name="internal" domain="$${domain}">), you can originate with the following:
sofia/<profile>/<extension>
And forego the domain when dialing local extensions.
Multiple Registrations
Call one extension and ring several phones
You must enable multiple registrations in sofia.conf
<param name="multiple-registrations" value="true"/>
The most likely place to put this is in a specific profile.
In your dialplan, call the extension using sofia_contact similar to the following:
<action application="bridge" data="${sofia_contact($${sip_profile}/${dialed_ext}@$${domain})}"/>
sofia_contact also works at the CLI, so you can test before you add it to your dialplan
See Function sofia contact for more informations.
Note (this applies to FS 1.0.1 and later): you can disable multiple registrations on a per-user basis by setting the variable "sip-allow-multiple-registrations" to "false" in the directory. In this case, that single user won't be allowed to use multiple registrations.
Flushing Inbound Registrations
From time to time, you may need to kill a registration.
you can kill a registration from the cli, or anywhere that accepts api commands with a command similar to the following
sofia profile <profile_name_here> flush_inbound_reg [optional_callid]
Dial out of a gateway
Basic form:
sofia/gateway/<gateway>/<number_to_dial>
Example 1:
sofia/gateway/asterlink/18005551212
gateway: is a keyword and not a "gateway" name. It has special meaning and tells the stack which credentials to use when challenged for the call.
<gateway> is the actual name of the gateway through which you want to send the call
Your available gateways (usually configured in conf/sip_profiles/default/*.xml) will show up in sofia status:
freeswitch#> sofia status
Name Type Data State
=================================================================================================
default profile sip:mod_sofia@2.3.4.5:5060 RUNNING (2)
mygateway gateway sip:username@1.2.3.4 NOREG
phonebooth.example.com alias default ALIASED
=================================================================================================
1 profile 1 alias
Modifying the To: header
You can override the To: header by appending ^<toheader>.
Example 1:
sofia/foo/user%192.168.1.1^101@$${domain}
Channel Variables
You can add arbitary headers to outbound SIP calls by prefixing the string 'sip_h_' to any channel variable, for example:
<action application="set" data="sip_h_X-Answer=42"/> <action application="bridge" data="sofia/mydomain.com/1000@example.com"/>
While not required, you should prefix your headers with "X-" to avoid issues with interoperability with other SIP stacks.
All inbound SIP calls will install any X- headers into local variables. This means you can easily bridge any X- header from one freeswitch instance to another.
Additional Variables
Additional variables may also be set to influence the way calls are handled by sofia.
For example, contacts can be filtered by setting the 'sip_exclude_contact' variable. Example:
<anti-action application="set" data="sip_exclude_contact=${network_addr}"/>
Transcoding Issues
G729 and G723 will not let you transcode because of licensing issues. Calls will fail if for example originating endpoint has set G729 with higher priority and receiving endpoint has G723 with highest priority. The logic is to fail the call rather than attempt to find a codec match. If you are having issues due to transcoding you may disable transcoding and both endpoints will negotiate the compatible codec rather than just fail the call.
add the following command <param name="disable-transcoding" value="true"/> to your freeswitch.xml
example
<configuration name="sofia.conf" description="sofia Endpoint">
<profiles>
<profile name="sip">
<settings>
<param name="disable-transcoding" value="true"/>
Custom Events
The following are events that can be subscribed to via Event Socket
- sofia::register
- sofia::expire
- sofia::gateway_state
- multicast::event
FAQ
Does it use UDP or TCP?
By default it uses both, but you can add ;tport=tcp to the sofia url to force it to use tcp.
For example:
sofia/profile/foo@bar.com;transport=tcp
Also there is a parameter in the gateway config:
<param name=”register-transport” value=”tcp”/>
That will cause it to use the tcp transport for the registration and all subsequent SIP messages.
Not sure if this is needed or what it does, but the following can also be used in gateway settings:
<!--extra sip params to send in the contact--> <param name="contact-params" value="tport=tcp"/>
See Also
- Debugging_Freeswitch
- SIP Protocol Messages
- Authentication params for gateways.
External links
http://opensource.nokia.com/projects/sofia-sip/
Categories: Sip | Events | Protocols
