diff --git a/docs/Asterisk-Community/Asterisk-Issue-Guidelines.md b/docs/Asterisk-Community/Asterisk-Issue-Guidelines.md index 55a7048169..00f5e82d59 100644 --- a/docs/Asterisk-Community/Asterisk-Issue-Guidelines.md +++ b/docs/Asterisk-Community/Asterisk-Issue-Guidelines.md @@ -18,7 +18,7 @@ Feature requests without patches are generally not accepted through the issue tr See the forums, mailing lists, IRC channels, or this wiki. For even more information, see * **Support requests**: (My phone doesn't register! My database connectivity doesn't work! How do I get it to work?) Search and ask on the forums, mailing lists, and IRC. Again, see for more information. -* **Random wishes and feature requests with no patch:** (I want Asterisk to support , but I don't know how to code!) +* **Random wishes and feature requests with no patch:** (I want Asterisk to support ``, but I don't know how to code!) See the [How to request a feature section](#how-to-request-a-feature-or-improvement) for more information on requesting a feature. * **Business development requests** (I will pay you to make Asterisk support fancy unicorn protocol!) Please head to the Commercial category at . If what you want is a specific feature or bug fixed, you may want to consider [requesting a bug bounty](/Development/Asterisk-Bug-Bounties). diff --git a/docs/Asterisk_20_Documentation/Upgrading.md b/docs/Asterisk_20_Documentation/Upgrading.md index 2dbda07f1b..cb169d5d69 100644 --- a/docs/Asterisk_20_Documentation/Upgrading.md +++ b/docs/Asterisk_20_Documentation/Upgrading.md @@ -13,7 +13,7 @@ in the amd.conf configuration file. ### app_bridgewait - * Adds the n option to not answer the channel when + * Adds the n option so as not to answer the channel when the BridgeWait application is called. ### features diff --git a/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-CLI-Commands.md b/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-CLI-Commands.md index b3d07b67fc..a63d3249ac 100644 --- a/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-CLI-Commands.md +++ b/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-CLI-Commands.md @@ -8,7 +8,7 @@ ConfBridge CLI Commands ConfBridge offers several commands that may be invoked from the Asterisk CLI. -confbridge kick +`confbridge kick ` -------------------------------------- Removes the specified channel from the conference, e.g.: @@ -19,7 +19,7 @@ Kicking SIP/mypeer-00000000 from confbridge 1111 ``` -On This Pageconfbridge list +`confbridge list` --------------- Shows a summary listing of all bridges, e.g.: @@ -32,7 +32,7 @@ Conference Bridge Name Users Marked Locked? ``` -confbridge list +`confbridge list ` ---------------------------- Shows a detailed listing of participants in a specified conference, e.g.: @@ -45,7 +45,7 @@ SIP/mypeer-00000001 default_user 1111 sample_user_menu ``` -confbridge lock +`confbridge lock ` ---------------------------- Locks a specified conference so that only Admin users can join, e.g.: @@ -56,7 +56,7 @@ Conference 1111 is locked. ``` -confbridge unlock +`confbridge unlock ` ------------------------------ Unlocks a specified conference so that only Admin users can join, e.g.: @@ -67,7 +67,7 @@ Conference 1111 is unlocked. ``` -confbridge mute +`confbridge mute ` -------------------------------------- Mutes a specified user in a specified conference, e.g.: @@ -78,7 +78,7 @@ Muting SIP/mypeer-00000001 from confbridge 1111 ``` -confbridge unmute +`confbridge unmute ` ---------------------------------------- Unmutes a specified user in a specified conference, e.g.: @@ -89,7 +89,7 @@ Unmuting SIP/mypeer-00000001 from confbridge 1111 ``` -confbridge record start +`confbridge record start ` ------------------------------------------- Begins recording a conference. If "file" is specified, it will be used, otherwise, the Bridge Profile record_file will be used. If the Bridge Profile does not specify a record_file, one will be automatically generated in Asterisk's monitor directory. Usage: @@ -101,7 +101,7 @@ Recording started ``` -confbridge record stop +`confbridge record stop ` ------------------------------------- Stops recording the specified conference, e.g.: @@ -114,7 +114,7 @@ Recording stopped. ``` -confbridge show menus +`confbridge show menus` --------------------- Shows a listing of Conference Menus as defined in confbridge.conf, e.g.: @@ -127,7 +127,7 @@ sample_user_menu ``` -confbridge show menu +`confbridge show menu ` -------------------------------- Shows a detailed listing of a named Conference Menu, e.g.: @@ -147,7 +147,7 @@ Name: sample_admin_menu ``` -confbridge show profile bridges +`confbridge show profile bridges` ------------------------------- Shows a listing of Bridge Profiles as defined in confbridge.conf, e.g.: @@ -160,7 +160,7 @@ default_bridge ``` -confbridge show profile bridge +`confbridge show profile bridge ` --------------------------------------- Shows a detailed listing of a named Bridge Profile, e.g.: @@ -193,7 +193,7 @@ sound_error_menu: conf-errormenu ``` -confbridge show profile users +`confbridge show profile users` ----------------------------- Shows a listing of User Profiles as defined in confbridge.conf, e.g.: @@ -206,7 +206,7 @@ default_user ``` -confbirdge show profile user +`confbirdge show profile user ` ----------------------------------- Shows a detailed listing of a named Bridge Profile, e.g.: diff --git a/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-Configuration.md b/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-Configuration.md index de14170f8b..3227f96d94 100644 --- a/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-Configuration.md +++ b/docs/Configuration/Applications/Conferencing-Applications/ConfBridge/ConfBridge-Configuration.md @@ -53,7 +53,7 @@ A Bridge Profile provides the following configuration options: | --- | --- | --- | --- | | type | bridge | Set this to bridge to configure a bridge profile | | | max_members | integer; e.g. 50 | Limits the number of participants for a single conference to a specific number. By default, conferences have no participant limit. After the limit is reached, the conference will be locked until someone leaves. Admin-level users are exempt from this limit and will still be able to join otherwise-locked, because of limit, conferences. | | -| record_conference | yes/no | Records the conference call starting when the first user enters the room, and ending when the last user exits the room. The default recorded filename is 'confbridge--.wav and the default format is 8kHz signed linear. By default, this option is disabled. This file will be located in the configured monitoring directory as set in asterisk.conf | | +| record_conference | yes/no | Records the conference call starting when the first user enters the room, and ending when the last user exits the room. The default recorded filename is `confbridge--.wav` and the default format is 8kHz signed linear. By default, this option is disabled. This file will be located in the configured monitoring directory as set in asterisk.conf | | | record_file | path, e.g. /tmp/myfiles | When record_conference is set to yes, the specific name of the recorded file can be set using this option. Note that since multiple conferences may use the same Bridge profile, this can cause issues, depending on the configuration. It is recommended to only use this option dynamically with the CONFBRIDGE() dialplan function. This allows the recorded name to be specified and a unique name to be chosen. By default, the recorded file is stored in Asterisk's spool/monitory directory, with a unique filename starting with the 'confbridge' prefix. | | | internal_sample_rate | auto, 8000, 12000, 16000, 24000, 32000, 44100, 48000, 96000, 192000 | Sets the internal native sample rate at which to mix the conference. The "auto" option allows Asterisk to adjust the sample rate to the best quality / performance based on the participant makeup. Numbered values lock the rate to the specified numerical rate. If a defined number does not match an internal sampling rate supported by Asterisk, the nearest sampling rate will be used instead. | | | mixing_interval | 10, 20, 40, 80 | Sets, in milliseconds, the internal mixing interval. By default, the mixing interval of a bridge is 20ms. This setting reflects how "tight" or "loose" the mixing will be for the conference. Lower intervals provide a "tighter" sound with less delay in the bridge and consume more system resources. Higher intervals provide a "looser" sound with more delay in the bridge and consume less resources | | @@ -68,7 +68,7 @@ A Bridge Profile provides the following configuration options: | sound_only_person | filename | The sound played when a user is the only person in the conference. | | | sound_only_one | filename | The sound played to a user when there is only one other person in the conference. | | | sound_there_are | filename | The sound played when announcing how many users there are in a conference. | | -| sound_other_in_party | filename | Used in conjunction with the sound_there_are option, used like "sound_there_are" "sound_other_in_party" | | +| sound_other_in_party | filename | Used in conjunction with the sound_there_are option, used like `"sound_there_are" "sound_other_in_party"` | | | sound_place_into_conference | filename | The sound played when someone is placed into a conference, after waiting for a marked user. | | | sound_wait_for_leader | filename | The sound played when a user is placed into a conference that cannot start until a marked user enters. | | | sound_leader_has_left | filename | The sound played when the last marked user leaves the conference. | | @@ -144,8 +144,8 @@ A Conference Menu provides the following configuration options: | Option | Values | Description | Notes | | --- | --- | --- | --- | | type | menu | Set this to menu to configure a conference menu | | -| playback | (&&...) | Plays back an audio file, or a string of audio files chained together using the & character, to the user and then immediately returns them to the conference. | | -| playback_and_continue | (&&...) | Plays back an audio file, or a series of audio files chained together using the & character, to the user while continuing the collect the DTMF sequence. This is useful when using a menu prompt that describes all of the menu options. Note that any DTMF during this action will terminate the prompt's playback. | | +| playback | (`&&...`) | Plays back an audio file, or a string of audio files chained together using the & character, to the user and then immediately returns them to the conference. | | +| playback_and_continue | (`&&...`) | Plays back an audio file, or a series of audio files chained together using the & character, to the user while continuing the collect the DTMF sequence. This is useful when using a menu prompt that describes all of the menu options. Note that any DTMF during this action will terminate the prompt's playback. | | | toggle_mute | | Toggles mute on and off. When a user is muted, they will not be able to speak to other conference users, but they can still listen to other users. While muted, DTMF keys from the caller will continue to be collected. | | | no_op | | This action does nothing. Its only real purpose exists for being able to reserve a sequence in the configuration as a menu exit sequence. | | | decrease_listening_volume | | Decreases the caller's listening volume. Everything they hear will sound quieter. | | diff --git a/docs/Configuration/Applications/External-IVR-Interface.md b/docs/Configuration/Applications/External-IVR-Interface.md index 9265decfb6..9ae19d4adc 100644 --- a/docs/Configuration/Applications/External-IVR-Interface.md +++ b/docs/Configuration/Applications/External-IVR-Interface.md @@ -92,7 +92,7 @@ The child process can send one of the following commands: * `P,TIMESTAMP` * `T,TIMESTAMP` -The `S` command checks to see if there is a playable audio file with the specified name, and if so, clears the generator's playlist and places the file onto the list. Note that the playability check does not take into account transcoding requirements, so it is possible for the file to not be played even though it was found. If the file does not exist it sends a `Z` response with the data element set to the file requested. If the generator is not currently playing silence, then `T` and `D` events will be sent to signal the playlist interruption and notify it of the files that will not be played. +The `S` command checks to see if there is a playable audio file with the specified name, and if so, clears the generator's playlist and places the file onto the list. Note that the playability check does not take into account transcoding requirements, so it is possible for the file not to be played even though it was found. If the file does not exist it sends a `Z` response with the data element set to the file requested. If the generator is not currently playing silence, then `T` and `D` events will be sent to signal the playlist interruption and notify it of the files that will not be played. The `A` command checks to see if there is a playable audio file with the specified name, and if so, appends it to the generator's playlist. The same playability and exception rules apply as for the `S` command. diff --git a/docs/Configuration/Applications/SMS.md b/docs/Configuration/Applications/SMS.md index b9bc095cf4..bf212831db 100644 --- a/docs/Configuration/Applications/SMS.md +++ b/docs/Configuration/Applications/SMS.md @@ -32,13 +32,13 @@ All text messages are stored in /var/spool/asterisk/sms A log is recorded in /var/log/asterisk/sms -There are two subdirectories called sc-me. holding all messages from service centre to phone, and me-sc. holding all messages from phone to service centre. +There are two subdirectories called `sc-me.` holding all messages from service centre to phone, and `me-sc.` holding all messages from phone to service centre. In each directory are messages in files, one per file, using any filename not starting with a dot. -When connected as a service centre, SMS(s) will send all messages waiting in the sc-me- directory, deleting the files as it goes. Any received in this mode are placed in the me-sc- directory. +When connected as a service centre, SMS(s) will send all messages waiting in the `sc-me-` directory, deleting the files as it goes. Any received in this mode are placed in the `me-sc-` directory. -When connected as a client, SMS() will send all messages waiting in the me-sc- directory, deleting the files as it goes. Any received in this mode are placed in the sc-me- directory. +When connected as a client, SMS() will send all messages waiting in the `me-sc-` directory, deleting the files as it goes. Any received in this mode are placed in the `sc-me-` directory. Message files created by SMS() use a time stamp/reference based filename. diff --git a/docs/Configuration/Applications/Voicemail/Message-Waiting-Indication.md b/docs/Configuration/Applications/Voicemail/Message-Waiting-Indication.md index 9e672b5280..88864d6961 100644 --- a/docs/Configuration/Applications/Voicemail/Message-Waiting-Indication.md +++ b/docs/Configuration/Applications/Voicemail/Message-Waiting-Indication.md @@ -59,7 +59,7 @@ Asterisk can subscribe to receive MWI from another SIP server and store it local ``` -MWI received will be stored in the 1234 mailbox of the SIP_Remote context. It can be used by other phones by setting their SIP peers "mailbox" option to the @SIP_Remote. e.g. mailbox=1234@SIP_Remote +MWI received will be stored in the 1234 mailbox of the SIP_Remote context. It can be used by other phones by setting their SIP peers "mailbox" option to the `@SIP_Remote`. e.g. `mailbox=1234@SIP_Remote` Reception of unsolicited MWI NOTIFY with chan_sip -------------------------------------------------- @@ -72,7 +72,7 @@ A chan_sip peer can be configured to receive unsolicited MWI NOTIFY messages and ``` -If the remote SIP server sends an unsolicited MWI NOTIFY message the new/old message count will be stored in the configured virtual mailbox. It can be used by any device supporting MWI by specifying mailbox=@SIP_Remote as the mailbox for the desired SIP peer. +If the remote SIP server sends an unsolicited MWI NOTIFY message the new/old message count will be stored in the configured virtual mailbox. It can be used by any device supporting MWI by specifying `mailbox=@SIP_Remote` as the mailbox for the desired SIP peer. res_external_mwi ------------------ @@ -91,4 +91,4 @@ External sources can use the API provided by res_external_mwi to communicate MWI chan_pjsip ----------- -The endpoint parameter `incoming_mwi_mailbox` (introduced in 13.18.0 and 14.7.0) takes a <`mailbox>@` value. When an unsolicited NOTIFY message is received ***from*** this endpoint with an event type of `message-summary` and the `incoming_mwi_mailbox` parameter is set, Asterisk will automatically publish the new/old message counts for the specified mailbox on the internal stasis bus for any other module to use. For instance, if you have an analog phone and you specify `mailbox=userx@default` in chan_dahdi.conf, when a NOTIFY comes in on a pjsip endpoint with `incoming_mwi_mailbox=userx@default`, chan_dahdi will automatically pick that up and turn the MWI light on on the analog phone. +The endpoint parameter `incoming_mwi_mailbox` (introduced in 13.18.0 and 14.7.0) takes a `@` value. When an unsolicited NOTIFY message is received ***from*** this endpoint with an event type of `message-summary` and the `incoming_mwi_mailbox` parameter is set, Asterisk will automatically publish the new/old message counts for the specified mailbox on the internal stasis bus for any other module to use. For instance, if you have an analog phone and you specify `mailbox=userx@default` in chan_dahdi.conf, when a NOTIFY comes in on a pjsip endpoint with `incoming_mwi_mailbox=userx@default`, chan_dahdi will automatically pick that up and turn the MWI light on on the analog phone. diff --git a/docs/Configuration/Channel-Drivers/Local-Channel/Local-Channel-Modifiers.md b/docs/Configuration/Channel-Drivers/Local-Channel/Local-Channel-Modifiers.md index b18b6564d7..b4fdca5fdc 100644 --- a/docs/Configuration/Channel-Drivers/Local-Channel/Local-Channel-Modifiers.md +++ b/docs/Configuration/Channel-Drivers/Local-Channel/Local-Channel-Modifiers.md @@ -25,7 +25,7 @@ Local/101@mycontext/nj ## List of Modifiers -* 'n' - Instructs the Local channel to not do a native transfer (the "n" stands for *No release*) upon the remote end answering the line. This is an esoteric, but important feature if you expect the Local channel to handle calls exactly like a normal channel. If you do not have the "no release" feature set, then as soon as the destination (inside of the Local channel) answers the line and one audio frame passes, the variables and dial plan will revert back to that of the original call, and the Local channel will become a zombie and be removed from the active channels list. This is desirable in some circumstances, but can result in unexpected dialplan behavior if you are doing fancy things with variables in your call handling. Read about [Local Channel Optimization](../Local-Channel-Optimization) to better understand when this option is necessary. +* 'n' - Instructs the Local channel not to do a native transfer (the "n" stands for *No release*) upon the remote end answering the line. This is an esoteric, but important feature if you expect the Local channel to handle calls exactly like a normal channel. If you do not have the "no release" feature set, then as soon as the destination (inside of the Local channel) answers the line and one audio frame passes, the variables and dial plan will revert back to that of the original call, and the Local channel will become a zombie and be removed from the active channels list. This is desirable in some circumstances, but can result in unexpected dialplan behavior if you are doing fancy things with variables in your call handling. Read about [Local Channel Optimization](../Local-Channel-Optimization) to better understand when this option is necessary. * 'j' - Allows you to use the generic jitterbuffer on incoming calls going to Asterisk applications. For example, this would allow you to use a jitterbuffer for an incoming SIP call to Voicemail by putting a Local channel in the middle. The 'j' option must be used in conjunction with the 'n' option to make sure that the Local channel does not get optimized out of the call. * 'm' - Will cause the Local channel to forward music on hold (MoH) start and stop requests. Normally the Local channel acts on them and it is started or stopped on the Local channel itself. This options allows those requests to be forwarded through the Local channel. * 'b' - This option causes the Local channel to return the actual channel that is behind it when queried. This is useful for transfer scenarios as the actual channel will be transferred, not the Local channel. diff --git a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Exchanging-Device-and-Mailbox-State-Using-PJSIP.md b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Exchanging-Device-and-Mailbox-State-Using-PJSIP.md index 2a8ac44e8e..d88e99092c 100644 --- a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Exchanging-Device-and-Mailbox-State-Using-PJSIP.md +++ b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Exchanging-Device-and-Mailbox-State-Using-PJSIP.md @@ -6,7 +6,7 @@ pageid: 29393398 Background ---------- -Asterisk has permitted the exchange of device and mailbox state for many versions. This has normally been accomplished using the res_xmpp module for instances across networks or using res_corosync for instances on the same network. This has required, in some cases, an extreme amount of work to setup. In the case of res_xmpp this also adds another point of failure for the exchange in the form of the XMPP server itself. The res_pjsip_publish_asterisk module on the other hand does not suffer from this. +Asterisk has permitted the exchange of device and mailbox state for many versions. This has normally been accomplished using the res_xmpp module for instances across networks or using res_corosync for instances on the same network. This has required, in some cases, an extreme amount of work to set up. In the case of res_xmpp this also adds another point of failure for the exchange in the form of the XMPP server itself. The res_pjsip_publish_asterisk module on the other hand does not suffer from this. Operation --------- diff --git a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Migrating-from-chan_sip-to-res_pjsip.md b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Migrating-from-chan_sip-to-res_pjsip.md index dd9eb6ee5f..d367478469 100644 --- a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Migrating-from-chan_sip-to-res_pjsip.md +++ b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Migrating-from-chan_sip-to-res_pjsip.md @@ -60,7 +60,7 @@ This examples shows the configuration required for: * two SIP phones need to make calls to or through Asterisk, we also want to be able to call them from Asterisk * for them to be identified as users (in the old chan_sip) or endpoints (in the new res_sip/chan_pjsip) * both devices need to use username and password authentication -* 6001 is setup to allow registration to Asterisk, and 6002 is setup with a static host/contact +* 6001 is set up to allow registration to Asterisk, and 6002 is set up with a static host/contact | sip.conf | pjsip.conf | | --- | --- | diff --git a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Authentication.md b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Authentication.md index 899336eb72..44a050f6f4 100644 --- a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Authentication.md +++ b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Authentication.md @@ -117,7 +117,7 @@ SHA2-512/256(stdin)= f8c3d34ce5ae6550740eaed0bff78a8aed354e87f2364813e4dbe9624bf You can specify multiple `password_digest` parameters in an auth object but no more than one for each digest hash algorithm. /// note | Line Endings -Note that the examples show using the `-n` parameter in the `echo` command. This tells `echo` to not output any line endings after printing the string. This is important because you don't want those line endings included in the hash calculation. +Note that the examples show using the `-n` parameter in the `echo` command. This tells `echo` not to output any line endings after printing the string. This is important because you don't want those line endings included in the hash calculation. /// /// warning | Algorithm Names diff --git a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Configuration-Sections-and-Relationships.md b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Configuration-Sections-and-Relationships.md index 487f68795e..57a6b08a84 100644 --- a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Configuration-Sections-and-Relationships.md +++ b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/PJSIP-Configuration-Sections-and-Relationships.md @@ -28,7 +28,7 @@ Reference documentation for all configuration parameters: * [Configuration options for outbound registration, provided by res_pjsip_outbound_registration](/Latest_API/API_Documentation/Module_Configuration/res_pjsip_outbound_registration) * [Configuration options for endpoint identification by IP address, provided by res_pjsip_endpoint_identifier_ip](/Latest_API/API_Documentation/Module_Configuration/res_pjsip_endpoint_identifier_ip) -The same documentation is available at the Asterisk CLI as well. You can use "config show help " to get help on a particular option. That help will typically describe the default value for an option as well. +The same documentation is available at the Asterisk CLI as well. You can use `config show help ` to get help on a particular option. That help will typically describe the default value for an option as well. /// tip|Defaults For many config options, it's very helpful to understand their default behavior. For example, for the endpoint section "transport=" option, if no value is assigned then Asterisk will \*DEFAULT\* to the first configured transport in pjsip.conf which is valid for the URI we are trying to contact. @@ -80,7 +80,7 @@ callerid=Spaceman Spiff <6001> Configure how res_pjsip will operate at the transport layer. For example, it supports configuration options for protocols such as TCP, UDP or WebSockets and encryption methods like TLS/SSL. -You can setup multiple transport sections and other sections (such as endpoints) could each use the same transport, or a unique one. However, there are a couple caveats for creating multiple transports: +You can set up multiple transport sections and other sections (such as endpoints) could each use the same transport, or a unique one. However, there are a couple caveats for creating multiple transports: * They cannot share the same IP+port or IP+protocol combination. That is, each transport that binds to the same IP as another must use a different port or protocol. * PJSIP does not allow multiple TCP or TLS transports of the same IP version (IPv4 or IPv6). @@ -201,7 +201,7 @@ EXAMPLE BASIC CONFIGURATION This example shows you how you might configure registration and outbound authentication against another Asterisk system, where the other system is using the older chan_sip peer setup. -This example is just the registration itself. You'll of course need the associated transport and auth sections. Plus, if you want to receive calls from the far end (who now knows where to send calls, thanks to your registration!) then you'll need endpoint, AOR and possibly identify sections setup to match inbound calls to a context in your dialplan. +This example is just the registration itself. You'll of course need the associated transport and auth sections. Plus, if you want to receive calls from the far end (who now knows where to send calls, thanks to your registration!) then you'll need endpoint, AOR and possibly identify sections set up to match inbound calls to a context in your dialplan. ``` [mytrunk] diff --git a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Setting-up-PJSIP-Realtime.md b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Setting-up-PJSIP-Realtime.md index adbfd65439..745926d97d 100644 --- a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Setting-up-PJSIP-Realtime.md +++ b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Setting-up-PJSIP-Realtime.md @@ -78,7 +78,7 @@ Then rename the config.ini.sample file to config.ini ``` -Finally, use Alembic to setup the database tables: +Finally, use Alembic to set up the database tables: ```bash title=" " linenums="1" # alembic -c config.ini upgrade head @@ -126,7 +126,7 @@ mysql> quit ## Configuring ODBC -Now that we have our MySQL database created and populated, we'll need to setup ODBC and Asterisk's ODBC resource to access the database. First, we'll tell ODBC how to connect to MySQL. To do this, we'll edit the **/etc/odbcinst.ini** configuration file. Your file should look something like: +Now that we have our MySQL database created and populated, we'll need to set up ODBC and Asterisk's ODBC resource to access the database. First, we'll tell ODBC how to connect to MySQL. To do this, we'll edit the **/etc/odbcinst.ini** configuration file. Your file should look something like: ```conf title="/etc/odbcinst.ini" [MySQL] diff --git a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/res_pjsip-Remote-Attended-Transfers.md b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/res_pjsip-Remote-Attended-Transfers.md index 8b1f54c3fe..d5fad0af1e 100644 --- a/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/res_pjsip-Remote-Attended-Transfers.md +++ b/docs/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/res_pjsip-Remote-Attended-Transfers.md @@ -79,7 +79,7 @@ The big reason why Asterisk calls into the dialplan instead of automatically sen Writing your `external_replaces` extension ========================================== -Now that the theory has been presented, you'll need to write your `external_replaces` extension. One option you have is to not write an `external_replaces` extension at all. This will prevent any remote attended transfers from succeeding. +Now that the theory has been presented, you'll need to write your `external_replaces` extension. One option you have is not to write an `external_replaces` extension at all. This will prevent any remote attended transfers from succeeding. If you do want to write an `external_replaces` extension, the first thing you want to do is determine if you want to perform the remote attended transfer. `SIPREFERTOHDR`, and values provided by the `CHANNEL()` dialplan function can help you to decide if you want to allow the transfer. For instance, you might use `CHANNEL(endpoint)` to see which PJSIP endpoint is performing the transfer, and you can inspect `SIPREFERTOHDR` to determine if the transfer is destined for a trusted domain. diff --git a/docs/Configuration/Channel-Drivers/Unistim/Introduction-to-the-Unistim-channel.md b/docs/Configuration/Channel-Drivers/Unistim/Introduction-to-the-Unistim-channel.md index 6abadf9da2..a66d5959c7 100644 --- a/docs/Configuration/Channel-Drivers/Unistim/Introduction-to-the-Unistim-channel.md +++ b/docs/Configuration/Channel-Drivers/Unistim/Introduction-to-the-Unistim-channel.md @@ -183,8 +183,8 @@ You can use the following entries in unistim.conf * As always, NAT can be tricky. If a phone is behind a NAT, you should port forward UDP 5000 (or change [general] port= in unistim.conf) and UDP 10000 (or change [yourphone] rtp_port=) * Only one phone per public IP (multiple phones behind the same NAT don't work). You can either : - + Setup a VPN - + Install asterisk inside your NAT. You can use IAX2 trunking if you're master asterisk is outside. + + Set up a VPN + + Install asterisk inside your NAT. You can use IAX2 trunking if your master asterisk is outside. + If asterisk is behind a NAT, you must set [general] public_ip= with your public IP. If you don't do that or the bindaddr is invalid (or no longer valid, eg dynamic IP), phones should be able to display messages but will be unable to send/receive RTP packets (no sound) * Don't forget : this work is based entirely on a reverse engineering, so you may encounter compatibility issues. At this time, I know three ways to establish a RTP session. You can modify [yourphone] rtp_method= with 0, 1, 2 or 3. 0 is the default method, should work. 1 can be used on new firmware (black i2004) and 2 on old violet i2004. 3 can be used on black i2004 with chrome. * If you have difficulties, try unistim debug and set verbose 3 on the asterisk CLI. For extra debug, uncomment #define DUMP_PACKET 1 and recompile chan_unistim. diff --git a/docs/Configuration/Functions/Manipulating-Party-ID-Information.md b/docs/Configuration/Functions/Manipulating-Party-ID-Information.md index 4817f9de9f..a31636c524 100644 --- a/docs/Configuration/Functions/Manipulating-Party-ID-Information.md +++ b/docs/Configuration/Functions/Manipulating-Party-ID-Information.md @@ -32,7 +32,7 @@ The CALLERID information is passed during the initial call setup. However, depen ### CONNECTEDLINE dialplan function -The CONNECTEDLINE function does the opposite of the CALLERID function. CONNECTEDLINE can be used to setup connected line information to be sent when the call is answered. You can use it to send new connected line information to the remote party on the channel when a call is transferred. The CONNECTEDLINE information is passed when the call is answered and when the call is transferred. +The CONNECTEDLINE function does the opposite of the CALLERID function. CONNECTEDLINE can be used to set up connected line information to be sent when the call is answered. You can use it to send new connected line information to the remote party on the channel when a call is transferred. The CONNECTEDLINE information is passed when the call is answered and when the call is transferred. !!! note It is up to the channel technology to determine when to act upon connected line updates before the call is answered. ISDN will just store the updated information until the call is answered. SIP could immediately update the caller with a provisional response or wait for some other event to notify the caller. @@ -51,8 +51,8 @@ The incoming call may have already been redirected. An incoming call has already There are several things to do when a call is forwarded by the dialplan: -* Setup the REDIRECTING(to-xxx) values to be sent to the caller. -* Setup the REDIRECTING(from-xxx) values to be sent to the new destination. +* Set up the REDIRECTING(to-xxx) values to be sent to the caller. +* Set up the REDIRECTING(from-xxx) values to be sent to the new destination. * Increment the REDIRECTING(count). * Set the REDIRECTING(reason). * Dial() the new destination. @@ -67,7 +67,7 @@ For redirected calls out a trunk line, you need to use the 'i' option on all of ### Dial() and Queue() dialplan application 'I' option -In the dialplan applications Dial() and Queue(), the 'I' option is a brute force option to block connected line and redirecting information updates while the application is running. Blocking the updates prevents the update from overwriting any CONNECTEDLINE or REDIRECTING values you may have setup before running the application. +In the dialplan applications Dial() and Queue(), the 'I' option is a brute force option to block connected line and redirecting information updates while the application is running. Blocking the updates prevents the update from overwriting any CONNECTEDLINE or REDIRECTING values you may have set up before running the application. The option blocks all redirecting updates since they should only happen before a call is answered. The option only blocks the connected line update from the initial answer. Connected line updates resulting from call transfers happen after the application has completed. Better control of connected line and redirecting information is obtained using the interception macros. diff --git a/docs/Configuration/Interfaces/Asterisk-Call-Files.md b/docs/Configuration/Interfaces/Asterisk-Call-Files.md index 3ff87c74f1..6dcfe71332 100644 --- a/docs/Configuration/Interfaces/Asterisk-Call-Files.md +++ b/docs/Configuration/Interfaces/Asterisk-Call-Files.md @@ -30,7 +30,7 @@ The call file consists of : pairs; one per line. Comments are indicated by a '#' character that begins a line, or follows a space or tab character. To be consistent with the configuration files in Asterisk, comments can also be indicated by a semicolon. However, the multiline comments (;----;) used in Asterisk configuration files are not supported. Semicolons can be escaped by a backslash. -The following keys-value pairs are used to specify how setup a call: +The following keys-value pairs are used to specify how to set up a call: * `Channel: ` - The channel to use for the new call, in the form **technology/resource** as in the Dial application. This value is required. * `Callerid: ` - The caller id to use. diff --git a/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/AMI-v2-Specification/index.md b/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/AMI-v2-Specification/index.md index e335cf34d6..06e6a42143 100644 --- a/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/AMI-v2-Specification/index.md +++ b/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/AMI-v2-Specification/index.md @@ -41,7 +41,7 @@ Asterisk provides a number of interfaces that serve different purposes. Say, for | --- | --- | | ... we want to use a local script to execute some logic on Alice's channel | AGI | | ... we want to execute a script on a remote machine on Bob's channel | FastAGI | -| ... we want to put Alice into an IVR with fine grained media control, where the IVR is written outside of `extensions.conf` | ExternalIVR | +| ... we want to put Alice into an IVR with fine grained media control, where the IVR is written outside of `extensions.conf` | ExternalIVR | | ... we want to control Alice and Bob's underlying channel objects at some asynchronous time | AMI (possibly with AsyncAGI) | | ... we want to write our own Dialling application to control both Alice and Bob | ARI | @@ -59,7 +59,6 @@ Sometimes, the term **command** may be used instead of the term **action**. With Historically, AMI has existed in Asterisk as its own core component `manager`. AMI events were raised throughout Asterisk encoded in an AMI specific format, and AMI actions were processed and passed to the functions that implemented the logic. In Asterisk 12, AMI has been refactored to sit on top of Stasis, a generic, protocol independent message bus internal to Asterisk. From the perspective of clients wishing to communicate with Asterisk over AMI very little has changed; internally, the Stasis representation affords a much higher degree of flexibility with how messages move through Asterisk. It also provides a degree of uniformity for information that is propagated to interested parties. -  AMI High Level Diagram: ![AMI High Level Diagram](AMI-High-Level-Diagram.png) @@ -72,7 +71,7 @@ Stasis acts as a generic publish/subscribe message bus inside of Asterisk. While By default, AMI is an asynchronous protocol that sends events immediately to clients when those events are available. Likewise, clients are free to send actions to AMI at any time, which may or may not trigger additional events. The exception to this is when the connection is over HTTP; in that scenario, events are only transmitted as part of the response to an HTTP POST. -Various options for configuration of clients can control which events are sent to a client. Events can be whitelisted/blacklisted explicitly via event filters, or implicitly by class authorizations. +Various options for configuration of clients can control which events are sent to a client. Events can be whitelisted/blacklisted explicitly via event filters, or implicitly by class authorizations. ### Message Layout @@ -144,7 +143,7 @@ CallerID: "Kermit the Frog" <123-4567> Priority: 1 ``` -This is also true for events, although by convention, the `Event` key is the first key in the event. If an action or event contains duplicate keys, such as `Variable`, the order in which Asterisk processes said keys is the order in which they occur within the action or event. +This is also true for events, although by convention, the `Event` key is the first key in the event. If an action or event contains duplicate keys, such as `Variable`, the order in which Asterisk processes said keys is the order in which they occur within the action or event. Keys are case insensitive. Hence, the following keys are equivalent: @@ -181,7 +180,9 @@ It is up to the client to ensure that the **ActionId** provided with an **Action This section lists fields that apply generally to all actions that interact upon an Asterisk channel. Note that an Action that interacts with a channel \*must\* supply the \*Channel\* field. -Upgrading In the past, AMI clients would have to contend with channel rename events. As Asterisk will now no longer change the name of a channel during its lifetime, this is no longer necessary. +/// note | Upgrading +In the past, AMI clients would have to contend with channel rename events. As Asterisk will now no longer change the name of a channel during its lifetime, this is no longer necessary. +/// /// define Channel @@ -226,11 +227,11 @@ Events that relate multiple channels will prefix these fields with an event spec /// define Channel -- The current Asterisk channel name. This corresponds to the Channel field in actions. +- The current Asterisk channel name. This corresponds to the Channel field in actions. Uniqueid -- A universal unique identifier for the channel. This corresponds to the Uniqueid field in actions. +- A universal unique identifier for the channel. This corresponds to the Uniqueid field in actions. ChannelState @@ -253,7 +254,7 @@ Depending on the underlying channel technology, not all states will be used. Cha ChannelStateDesc -- The text description of the channel state. This will be one of the State descriptions in the table in ChannelState. +- The text description of the channel state. This will be one of the State descriptions in the table in ChannelState. CallerIDNum @@ -289,7 +290,7 @@ Priority ChanVariable -- Channel variables specific to a channel can be conveyed in each AMI event related to that channel. When this occurs, each variable is referenced in a **ChanVariable** field. The value of a **ChanVariable** field will always be of the form `key=value`, where `key` is the name of the channel variable and `value` is its value. +- Channel variables specific to a channel can be conveyed in each AMI event related to that channel. When this occurs, each variable is referenced in a **ChanVariable** field. The value of a **ChanVariable** field will always be of the form `key=value`, where `key` is the name of the channel variable and `value` is its value. /// @@ -375,14 +376,14 @@ While channels are independent of AMI, they have a large implication on the even All channels begin with a **Newchannel** event. A **Newchannel** will always contain the following fields: -* The current Channel name that acts as a handle to the channel for that channel's lifetime for a single Asterisk system. +* The current Channel name that acts as a handle to the channel for that channel's lifetime for a single Asterisk system. * The Uniqueid for the channel, that allows systems to have a globally unique identifier for the channel. -Changes in the state of the channel, i.e., the ChannelState field, are conveyed via **Newstate** events. +Changes in the state of the channel, i.e., the ChannelState field, are conveyed via **Newstate** events. Notification of a Channel being disposed of occurs via a **Hangup** event. A **Hangup** signals the termination of the channel associated with the Uniqueid. After the **Hangup** event, no further events will be raised in relation to the channel with that Uniqueid, and the communication between the endpoint and Asterisk via that channel is terminated. -The examples in this specification do not show all of the fields in every event. For a full listing of all of the fields, see the documentation for the specific event in [AMI Events](/Latest_API/API_Documentation/AMI_Events/). +The examples in this specification do not show all of the fields in every event. For a full listing of all of the fields, see the documentation for the specific event in [AMI Events](/Latest_API/API_Documentation/AMI_Events/). Example: @@ -395,7 +396,7 @@ ChannelState: 0 ChannelStateDesc: Down ``` -* Kermit the Frog's SIP channel is created. The is the first event for `PJSIP/kermit-00000001` and indicates a path of communication being opened up between Asterisk and Kermit's SIP device. +* Kermit the Frog's SIP channel is created. The is the first event for `PJSIP/kermit-00000001` and indicates a path of communication being opened up between Asterisk and Kermit's SIP device. ``` Event: Newstate @@ -419,11 +420,11 @@ Cause: 16 Cause-txt: Normal Clearing ``` -* Kermit the Frog's PJSIP channel is hung up. At this point, no further events for `PJSIP/kermit-00000001` will be sent. +* Kermit the Frog's PJSIP channel is hung up. At this point, no further events for `PJSIP/kermit-00000001` will be sent. #### Channel Variables -For each channel variable that is changed, a **VarSet** event is sent to the client. The **VarSet** event contains the new value of the appropriate channel variable. Note that channel variables can also be conveyed in ChanVariable fields. +For each channel variable that is changed, a **VarSet** event is sent to the client. The **VarSet** event contains the new value of the appropriate channel variable. Note that channel variables can also be conveyed in ChanVariable fields. #### DTMF @@ -459,11 +460,11 @@ Note that even though Kermit has been hungup, we will not receive the **Hangup** Dial operations always result in two events: a **DialBegin** event that signals the beginning of the dial to a particular destination, and a **DialEnd** event that signals the end of the dialing. In parallel dialing situations, **DialBegin**/**DialEnd** events MUST be sent for each channel dialed. For each **DialBegin** event sent, there MUST be a corresponding **DialEnd** event. -In dialing situations with a caller and a called party, the **DialBegin** and **DialEnd** events convey information about both channels. The calling channel uses the standard channel field names, while the called party's field names are prefixed with "Dest". In dialing situations where there is no caller, such as when Asterisk originates an outbound call via a call file, only the called channel is represented in the events. The channel field names are still prefixed with "Dest" in this case; the standard channel field names are **not** present in the event in this case. +In dialing situations with a caller and a called party, the **DialBegin** and **DialEnd** events convey information about both channels. The calling channel uses the standard channel field names, while the called party's field names are prefixed with "Dest". In dialing situations where there is no caller, such as when Asterisk originates an outbound call via a call file, only the called channel is represented in the events. The channel field names are still prefixed with "Dest" in this case; the standard channel field names are **not** present in the event in this case. A **DialEnd** occurs whenever Asterisk knows the final state of the channel that it was attempting to establish. The status is communicated in the DialStatus field. -Behavior Change The **DialBegin**/**DialEnd** events replace the **Dial** event. Note that the **Dial** event signaling the end of dialing would not normally be sent until after bridging was complete; this operation will now occur when the dial operation has determined the status of a particular called channel. +Behavior Change The **DialBegin**/**DialEnd** events replace the **Dial** event. Note that the **Dial** event signaling the end of dialing would not normally be sent until after bridging was complete; this operation will now occur when the dial operation has determined the status of a particular called channel. Simple Successful Dial: @@ -484,7 +485,7 @@ Uniqueid: asterisk-1368479155.1 DestChannel: PJSIP/animal-00000002 DestUniqueid: asterisk-1368479160.5 DialStatus: ANSWER -...  +... ``` In this example, Kermit decides to dial Animal. A new channel between Asterisk and Animal's SIP device is created and conveyed via a **Newchannel** event, and then a dial operation is begun. Note that in the **DialBegin** event, Kermit's SIP device is the caller as he initiated the dial operation, while Animal's SIP device is the destination. As such, the fields referring to Animal's PJSIP channel are prefixed with "Dest". @@ -566,7 +567,7 @@ In this example, Kermit decides to dial Animal and Dr. Teeth. Dr. Teeth immediat A bridge contains 0 or more channels. When a channel is in a bridge, it has the potential to communicate with other channels within the bridge. Before channels enter a bridge, a **BridgeCreate** event is sent, indicating that a bridge has been created. When a bridge is destroyed, a **BridgeDestroy** event is sent. All channels within a bridge MUST leave a bridge prior to the **BridgeDestroy** event being sent. -When a channel enters a bridge, a **BridgeEnter** event is raised. When a channel is put into a bridge, it is implied that the channel can pass media between other channels in the bridge. This is not guaranteed, as other properties on the channel or bridge may restrict media flow. For example, bridges with a BridgeTechnology type of *holding**\_bridge* implicitly restrict the media flow between channels. Likewise, media may be restricted in multi-party conference bridges based on user role permissions, such as when a conference leader mutes all participants in a conference. The **BridgeEnter** event does indicate, however, that a potential relationship between channels in a bridge exists. +When a channel enters a bridge, a **BridgeEnter** event is raised. When a channel is put into a bridge, it is implied that the channel can pass media between other channels in the bridge. This is not guaranteed, as other properties on the channel or bridge may restrict media flow. For example, bridges with a BridgeTechnology type of *holding**\_bridge* implicitly restrict the media flow between channels. Likewise, media may be restricted in multi-party conference bridges based on user role permissions, such as when a conference leader mutes all participants in a conference. The **BridgeEnter** event does indicate, however, that a potential relationship between channels in a bridge exists. When a channel leaves a bridge, a corresponding **BridgeLeave** event is raised. A **BridgeLeave** event MUST mean that the channel that left the bridge can no longer pass media to other channels still in the bridge. This does not necessarily mean that the channel is being hung up; rather, that it is no longer in a communication path with some other set of channels. @@ -648,13 +649,13 @@ BridgeUniqueid: 1234 BridgeNumChannels: 0 ``` -Asterisk is configured to not let Gonzo continue on in the dialplan once his bridge is broken. As such, Gonzo is forcibly ejected from the bridge, and is hung up on after. Because no channels are left in the bridge, the bridge is destroyed. +Asterisk is configured not to let Gonzo continue on in the dialplan once his bridge is broken. As such, Gonzo is forcibly ejected from the bridge, and is hung up on after. Because no channels are left in the bridge, the bridge is destroyed. In this scenario, it was perfectly acceptable for either Kermit or Gonzo's channels to continue after the bridge was broken. Since this represents the most basic two-party call scenario, once one party decided to hang up, the other party was also hung up on. #### Transfers -Transfer information is conveyed with either a **BlindTransfer** or **AttendedTransfer** event, which indicates information about the transfer that took place. **BridgeLeave**/**BridgeEnter** events are used to indicate which channels are talking in which bridges at different stages during the transfer. +Transfer information is conveyed with either a **BlindTransfer** or **AttendedTransfer** event, which indicates information about the transfer that took place. **BridgeLeave**/**BridgeEnter** events are used to indicate which channels are talking in which bridges at different stages during the transfer. Transfers do a LotDepending on the type of transfer and the actions taken, channels will move in and out of a lot of bridges. The purpose of the two transfer events is to convey to the AMI client the overall completed status of the transfer after the users have completed their actions. With Blind Transfers, this typically happens very quickly: Asterisk simply has to determine that the destination of the transfer is a valid extension in the dialplan. @@ -801,7 +802,7 @@ Local channels have an option wherein they can be optimized away if both halves Two actions can take place when a Local channel optimizes between two bridges. -1. If, after the Local channel optimization, either bridge contains only a single channel, then a single channel in one of the bridges is moved to the bridge that has the other channel. This is conveyed by a sequence of **BridgeLeave**/**BridgeEnter** events. +1. If, after the Local channel optimization, either bridge contains only a single channel, then a single channel in one of the bridges is moved to the bridge that has the other channel. This is conveyed by a sequence of **BridgeLeave**/**BridgeEnter** events. 2. If, after the Local channel optimization, the bridges contain multiple parties, the bridges will be merged together. A **BridgeMerge** event is sent when this occurs. Channels will then be merged from one bridge to the other, denoted by a sequence of **BridgeLeave**/**BridgeEnter** events. It is not defined which channel is moved first or which bridge wins during a bridge merge. That is an implementation detail left up to Asterisk. Suffice to say, if a Local channel is optimized away, Asterisk attempts to rebridge the channels left over as fast as possible to prevent any loss in audio. @@ -985,7 +986,7 @@ The Local channel optimization completes by removing the Local channel halves fr ### Masquerades -Masquerades are goneIn the past, masquerades occurred rather frequently - most often in any scenario where a transfer occurred or where a `pbx_thread` needed to be associated with a channel. This has now changed. Masquerades now rarely occur, and are never communicated to AMI clients. From the perspective of AMI clients, nothing changes - you still use your handle to a channel to communicate with it, regardless of the presence (or lack thereof) of a masquerade operation. +Masquerades are goneIn the past, masquerades occurred rather frequently - most often in any scenario where a transfer occurred or where a `pbx_thread` needed to be associated with a channel. This has now changed. Masquerades now rarely occur, and are never communicated to AMI clients. From the perspective of AMI clients, nothing changes - you still use your handle to a channel to communicate with it, regardless of the presence (or lack thereof) of a masquerade operation. This section only exists to explicitly call out the fact that Masquerades are gone. @@ -1085,6 +1086,5 @@ Note that the name of the client settings context is the username for the client | read | String | A comma delineated list of the allowed class authorizations applied to events | all | | write | String | A comma delineated list of the allowed class authorizations applied to actions | all | -  The item has all class authorizations associated with it diff --git a/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/Asynchronous-Javascript-Asterisk-Manager-AJAM/Allow-Manager-Access-via-HTTP.md b/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/Asynchronous-Javascript-Asterisk-Manager-AJAM/Allow-Manager-Access-via-HTTP.md index 534afbc747..16efa31a0c 100644 --- a/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/Asynchronous-Javascript-Asterisk-Manager-AJAM/Allow-Manager-Access-via-HTTP.md +++ b/docs/Configuration/Interfaces/Asterisk-Manager-Interface-AMI/Asynchronous-Javascript-Asterisk-Manager-AJAM/Allow-Manager-Access-via-HTTP.md @@ -11,7 +11,7 @@ pageid: 4817260 Configuring manager.conf ------------------------ -1. Make sure you have both "enabled = yes" and "webenabled = yes" setup in /etc/asterisk/manager.conf +1. Make sure you have both "enabled = yes" and "webenabled = yes" set in /etc/asterisk/manager.conf 2. You may also use "httptimeout" to set a default timeout for HTTP connections. 3. Make sure you have a manager username/secret diff --git a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/LDAP-Realtime-Driver.md b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/LDAP-Realtime-Driver.md index c992e38091..e3cc29b858 100644 --- a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/LDAP-Realtime-Driver.md +++ b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/LDAP-Realtime-Driver.md @@ -6,7 +6,7 @@ pageid: 4260014 Asterisk Realtime Lightweight Directory Access Protocol (LDAP) Driver ===================================================================== -With this driver Asterisk, using the [Realtime Database Configuration](/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration), can access and update information in an LDAP directory. Asterisk can configure SIP/IAX2 users, extensions, queues, queue members, and entire configuration files. This guide assumes you have a working knowledge of LDAP and have an LDAP server with authentication already setup. Asterisk requires read and write permissions to update the directory. +With this driver Asterisk, using the [Realtime Database Configuration](/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration), can access and update information in an LDAP directory. Asterisk can configure SIP/IAX2 users, extensions, queues, queue members, and entire configuration files. This guide assumes you have a working knowledge of LDAP and have an LDAP server with authentication already set up. Asterisk requires read and write permissions to update the directory. See [configs/res_ldap.conf.sample](https://raw.githubusercontent.com/asterisk/asterisk/master/configs/samples/res_ldap.conf.sample) for a configuration file sample. See contrib/scripts for the LDAP [schema](https://raw.githubusercontent.com/asterisk/asterisk/master/contrib/scripts/asterisk.ldap-schema) and [ldif](https://raw.githubusercontent.com/asterisk/asterisk/master/contrib/scripts/asterisk.ldif) files needed for the LDAP server. diff --git a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/Managing-Realtime-Databases-with-Alembic.md b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/Managing-Realtime-Databases-with-Alembic.md index 5a03debc4c..8ea64b955e 100644 --- a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/Managing-Realtime-Databases-with-Alembic.md +++ b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/Managing-Realtime-Databases-with-Alembic.md @@ -2,58 +2,65 @@ title: Managing Realtime Databases with Alembic --- -Overview -======== +# Overview -Asterisk 12 now uses [Alembic](https://pypi.python.org/pypi/alembic) to help manage Asterisk Realtime Database schemas. This includes creation of SQL scripts for a variety of database vendors, but also much more. Alembic is a full database migration tool, with support for upgrading the schemas of existing databases, versioning of schemas, creation of new tables and databases, and a whole lot more. This page covers basic configuration of the Alembic configuration file for usage with Asterisk Realtime as well as basic usage of Alembic. While a full description of Alembic is beyond the scope of this page, the information on this page should help an Asterisk administrator create or upgrade an Asterisk installation. +Asterisk 12 now uses [Alembic](https://pypi.python.org/pypi/alembic) to help manage Asterisk Realtime Database schemas. This includes creation of SQL scripts for a variety of database vendors, but also much more. Alembic is a full database migration tool, with support for upgrading the schemas of existing databases, versioning of schemas, creation of new tables and databases, and a whole lot more. This page covers basic configuration of the Alembic configuration file for usage with Asterisk Realtime as well as basic usage of Alembic. While a full description of Alembic is beyond the scope of this page, the information on this page should help an Asterisk administrator create or upgrade an Asterisk installation. -Alembic makes upgrading less painfulAs Asterisk changes and new fields are made controllable via realtime, new Alembic change scripts are added so you will be able to simply run the Alembic upgrade command again in order to modify your database. +Alembic makes upgrading less painful. As Asterisk changes and new fields are made controllable via realtime, new Alembic change scripts are added so you will be able to simply run the Alembic upgrade command again in order to modify your database. -While Alembic helps with database migrations within a release series (e.g., Asterisk 13.x.x) it does not work very well when jumping to a different release series (e.g., jumping from Asterisk 13.x.x to Asterisk 15.x.x).  Data loss is possible when jumping to a different release series.  Before a new series (e.g., Asterisk 15.0.0) is initially released breaking changes can be introduced that can result in data loss. - -Always exercise due diligence and backup your database before upgrading.  Tables can be fixed easily.  Repopulating the data if it's lost however isn't. +While Alembic helps with database migrations within a release series (e.g., Asterisk 13.x.x) it does not work very well when jumping to a different release series (e.g., jumping from Asterisk 13.x.x to Asterisk 15.x.x). +- Data loss is possible when jumping to a different release series. +- Before a new series (e.g., Asterisk 15.0.0) is initially released breaking changes can be introduced that can result in data loss. +- Always exercise due diligence and backup your database before upgrading. +- Tables can be fixed easily. +- Repopulating the data if it's lost however isn't. Please read the CHANGES file and the applicable UPGRADE files for important information about what changed between revisions. -Before you Begin ----------------- +## Before you Begin -This tutorial assumes you already have some experience in setting up Realtime configuration with Asterisk for other modules. This page will not describe how to set up backend database connectors, and is written under the assumption that you will be using ODBC to connect to your database since the ODBC adaptor is capable of connecting to most commonly used database servers. For more information on configuring and setting up Asterisk Realtime, see Asterisk Realtime Database configuration. +This tutorial assumes you already have some experience in setting up Realtime configuration with Asterisk for other modules. This page will not describe how to set up backend database connectors, and is written under the assumption that you will be using ODBC to connect to your database since the ODBC adaptor is capable of connecting to most commonly used database servers. For more information on configuring and setting up Asterisk Realtime, see: [Asterisk Realtime Database configuration](/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration). -Installing Alembic -================== +## Installing Alembic If you don't already have Alembic installed, perform the following: This does assume that you have pip installed. If you do not have pip installed, easy\_install should work just as well. If you don't have [pip](https://github.com/pypa/pip) or easy\_install (or Python), then you should probably install those first. -$ pip install alembicAnd that's it! +```sh +pip install alembic +``` + +And that's it! + +## Building the Database Tables + -Building the Database Tables -============================ +Alembic scripts were added to Asterisk in Asterisk 12, and will allow you to automatically populate your database with tables for most of the commonly used configuration options. The scripts are located in the [Asterisk contrib/ast-db-manage](http://svn.asterisk.org/svn/asterisk/trunk/contrib/ast-db-manage/) folder: -Alembic scripts were added to Asterisk in Asterisk 12, and will allow you to automatically populate your database with tables for most of the commonly used configuration options. The scripts are located in the [Asterisk contrib/ast-db-manage](http://svn.asterisk.org/svn/asterisk/trunk/contrib/ast-db-manage/) folder: +```sh +$ cd contrib/ast-db-manage +``` -$ cd contrib/ast-db-manageFor the rest of this tutorial, we will assume that operations will be taken in the context of that directory. +For the rest of this tutorial, we will assume that operations will be taken in the context of that directory. -Configuring Alembic -------------------- +## Configuring Alembic -Within this directory, you will find a configuration sample file, `config.ini.sample`, which will need to be edited to connect to your database of choice. Open this file in your text editor of choice and then save a copy of this sample file as `config.ini` - this will serve as the configuration file you actually use with Alembic. +Within this directory, you will find a configuration sample file, `config.ini.sample`, which will need to be edited to connect to your database of choice. Open this file in your text editor of choice and then save a copy of this sample file as `config.ini` - this will serve as the configuration file you actually use with Alembic. -There are two different parameters in `config.ini` that require review: `sqlalchemy.url` and `script_location`. The first specifies the database to upgrade; the second which upgrades to perform. +There are two different parameters in `config.ini` that require review: `sqlalchemy.url` and `script_location`. The first specifies the database to upgrade; the second which upgrades to perform. -1. Update `sqlalchemy.url` to the URL for your database. An example is shown below for a MySQL database: +1. Update `sqlalchemy.url` to the URL for your database. An example is shown below for a MySQL database: -sqlalchemy.url = mysql://root:password@localhost/asteriskThis would connect to a MySQL database as user `root` with password `password`. The database is `asterisk`, located on `localhost`. Different databases will require different URL schemas; however, they should in general follow the format outlined above. Alembic supports many different database technologies, including `oracle`, `postgresql`, and `mssql`. +sqlalchemy.url = mysql://root:password@localhost/asteriskThis would connect to a MySQL database as user `root` with password `password`. The database is `asterisk`, located on `localhost`. Different databases will require different URL schemas; however, they should in general follow the format outlined above. Alembic supports many different database technologies, including `oracle`, `postgresql`, and `mssql`. -For more information, see the Alembic documentation on SQLAlchemy URLs:  -2. Update `script_location` to the schema to update. Asterisk currently supports two sets of schemas: +For more information, see the Alembic documentation on SQLAlchemy URLs: +2. Update `script_location` to the schema to update. Asterisk currently supports two sets of schemas: 1. `config` - the set of schemas for Asterisk Realtime databases 2. `voicemail` - the schema for ODBC VoiceMail -Executing the database upgrade ------------------------------- +## Executing the database upgrade + I'm sorry Dave, I'm afraid I can't let you do that.Using config.ini for Alembic will populate tables for all of the configuration objects that can be populated this way, so if you really don't want a table for sip peers, iax friends, voicemail, meetme, and music on hold, you may need to exercise a little fine control. Back up your database before continuing and be prepared to delete tables that you don't want when you are finished. @@ -61,8 +68,8 @@ Your config.ini should be ready for use at this point, so close your text editor $ alembic -c config.ini upgrade headAt this point, if you configured your config.ini to connect to the database properly, your tables should be ready. -Troubleshooting the upgrade ---------------------------- +## Troubleshooting the upgrade + **Symptom:** Running 'alembic -c config.ini upgrade head' fails with a traceback: @@ -76,8 +83,6 @@ ImportError: No module named MySQLdb**Solution**: You probably need the Python i For example, with Ubuntu, install the following package and then re-run your Alembic upgrade. -# apt-get install python-mysqldb  - -  - -  +```sh +apt-get install python-mysqldb +``` \ No newline at end of file diff --git a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Configuring-res_odbc.md b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Configuring-res_odbc.md index 8432f4d5f8..6910f176bd 100644 --- a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Configuring-res_odbc.md +++ b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Configuring-res_odbc.md @@ -22,7 +22,7 @@ Other pages on the wiki describe that process: [Using Menuselect to Select Asterisk Options](/Getting-Started/Installing-Asterisk/Installing-Asterisk-From-Source/Using-Menuselect-to-Select-Asterisk-Options) -When using menuselect, verify that the **func_odbc** (you'll probably be using that one), **res_odbc** (required) and **res_odbc_transaction** (required) modules will be built. Then, build Asterisk and make sure those modules were built and exist in */usr/lib/asterisk/modules** (or whatever directory you use). +When using menuselect, verify that the **func_odbc** (you'll probably be using that one), **res_odbc** (required) and **res_odbc_transaction** (required) modules will be built. Then, build Asterisk and make sure those modules were built and exist in **/usr/lib/asterisk/modules** (or whatever directory you use). Configure res_odbc.conf to connect to your ODBC installation ============================================================= @@ -60,6 +60,6 @@ If you don't have the **odbc** command at the CLI, check that * The res_odbc.so module exists and has proper permissions in /usr/lib/asterisk/modules/ * Your modules.conf to make sure the module isn't noloaded or being prevented from loading somehow -* Debug during Asterisk startup to look for messages regarding res_odbc.conf (see logger.conf to get things setup) +* Debug during Asterisk startup to look for messages regarding res_odbc.conf (see logger.conf to get things set up) If you the **odbc show** output shows "Connected: No" then you'll want to try connecting to your ODBC installation from other methods to verify it is working. The Linux tool **isql** is good for that. diff --git a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Getting-Asterisk-Connected-to-MySQL-via-ODBC.md b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Getting-Asterisk-Connected-to-MySQL-via-ODBC.md index c6ea7ea1b1..59f281d576 100644 --- a/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Getting-Asterisk-Connected-to-MySQL-via-ODBC.md +++ b/docs/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Getting-Asterisk-Connected-to-MySQL-via-ODBC.md @@ -195,6 +195,6 @@ See [Building and Installing Asterisk](/Getting-Started/Installing-Asterisk/Inst ### Configuring Asterisk's ODBC connection -The basic configuration for an Asterisk ODBC connection is handled in res_odbc.conf. You should check out the [Configuring res_odbc](/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Configuring-res_odbc) page and follow it using the DSN and database username and password you setup earlier. +The basic configuration for an Asterisk ODBC connection is handled in res_odbc.conf. You should check out the [Configuring res_odbc](/Configuration/Interfaces/Back-end-Database-and-Realtime-Connectivity/ODBC/Configuring-res_odbc) page and follow it using the DSN and database username and password you set up earlier. After you have the connection set up in Asterisk you are ready to then configure your database tables with the proper schema depending on what exactly you want to do with them. Asterisk comes with some helpful tools to do this, such as Alembic. See the [Managing Realtime Databases with Alembic](../../Managing-Realtime-Databases-with-Alembic) section to get started with Alembic if you are working towards an Asterisk Realtime setup. diff --git a/docs/Configuration/Interfaces/Distributed-Device-State/Corosync.md b/docs/Configuration/Interfaces/Distributed-Device-State/Corosync.md index 9804e1eb78..d7ae06a307 100644 --- a/docs/Configuration/Interfaces/Distributed-Device-State/Corosync.md +++ b/docs/Configuration/Interfaces/Distributed-Device-State/Corosync.md @@ -197,7 +197,7 @@ In the general section of the res_corosync.conf file we are specifying which eve * ###### Verifying Installation -If everything is setup correctly, you should see this output after executing a 'corosync show members' on the Asterisk CLI. +If everything is set up correctly, you should see this output after executing a 'corosync show members' on the Asterisk CLI. ``` diff --git a/docs/Configuration/Interfaces/Utilizing-the-StatsD-Dialplan-Application.md b/docs/Configuration/Interfaces/Utilizing-the-StatsD-Dialplan-Application.md index b03f3a5773..636728c960 100644 --- a/docs/Configuration/Interfaces/Utilizing-the-StatsD-Dialplan-Application.md +++ b/docs/Configuration/Interfaces/Utilizing-the-StatsD-Dialplan-Application.md @@ -13,7 +13,7 @@ Overview StatsD is a daemon used to aggregate statistics by using different metrics and then summarizing these statistics in a way that can be useful to the users. One of StatsD's most useful capabilities is its ability to use a graphing back-end to display the statistics graphically. StatsD makes this very simple by accepting statistics through a short, one-line command and then grouping and arranging the statistics for you. -This StatsD application is a dialplan application that is used to send statistics automatically whenever a call is made to an extension that employs the application. The user must provide the arguments to the application in the dialplan, but after that, the application will send statistics to StatsD without requiring the user to perform anymore actions whenever a call comes through that extension. +This StatsD application is a dialplan application that is used to send statistics automatically whenever a call is made to an extension that employs the application. The user must provide the arguments to the application in the dialplan, but after that, the application will send statistics to StatsD without requiring the user to perform any more actions whenever a call comes through that extension. Setup ----- diff --git a/docs/Configuration/Miscellaneous/Hangup-Cause-Mappings.md b/docs/Configuration/Miscellaneous/Hangup-Cause-Mappings.md index 8ba95961a2..abee0411e2 100644 --- a/docs/Configuration/Miscellaneous/Hangup-Cause-Mappings.md +++ b/docs/Configuration/Miscellaneous/Hangup-Cause-Mappings.md @@ -7,57 +7,57 @@ Asterisk Hangup Cause Code Mappings | Asterisk Value | ISDN Cause codes (Q.850 & Q.931 unless specified) | MFC/R2 | SIP/PJSIP | Motif | | --- | --- | --- | --- | --- | -| AST\_CAUSE\_NOT\_DEFINED | Cause not defined | OR2\_CAUSE\_UNSPECIFIED |   |   | +| AST\_CAUSE\_NOT\_DEFINED | Cause not defined | OR2\_CAUSE\_UNSPECIFIED | | | | AST\_CAUSE\_UNALLOCATED | 1. Unallocated (unassigned) number - |   | 404, 485, 604 |   | -| AST\_CAUSE\_NO\_ROUTE\_TRANSIT\_NET | 2. No route to specified transmit network |   |   |   | -| AST\_CAUSE\_NO\_ROUTE\_DESTINATION | 3. No route to destination |   | 420 |   | -| AST\_CAUSE\_MISDIALLED\_TRUNK\_PREFIX | 5. Misdialled trunk prefix (national use) |   |   |   | -| AST\_CAUSE\_CHANNEL\_UNACCEPTABLE | 6. Channel unacceptable |   |   |   | -| AST\_CAUSE\_CALL\_AWARDED\_DELIVERED | 7. Call awarded and being delivered in an established channel |   |   |   | -| AST\_CAUSE\_PRE\_EMPTED | ISUP - 8. Preemption |   |   |   | -| AST\_CAUSE\_NUMBER\_PORTED\_NOT\_HERE | 14. QoR: ported number |   |   |   | -| AST\_CAUSE\_NORMAL\_CLEARING | 16. Normal Clearing | OR2\_CAUSE\_NORMAL\_CLEARING |   | gone, success | + | | 404, 485, 604 | | +| AST\_CAUSE\_NO\_ROUTE\_TRANSIT\_NET | 2. No route to specified transmit network | | | | +| AST\_CAUSE\_NO\_ROUTE\_DESTINATION | 3. No route to destination | | 420 | | +| AST\_CAUSE\_MISDIALLED\_TRUNK\_PREFIX | 5. Misdialled trunk prefix (national use) | | | | +| AST\_CAUSE\_CHANNEL\_UNACCEPTABLE | 6. Channel unacceptable | | | | +| AST\_CAUSE\_CALL\_AWARDED\_DELIVERED | 7. Call awarded and being delivered in an established channel | | | | +| AST\_CAUSE\_PRE\_EMPTED | ISUP - 8. Preemption | | | | +| AST\_CAUSE\_NUMBER\_PORTED\_NOT\_HERE | 14. QoR: ported number | | | | +| AST\_CAUSE\_NORMAL\_CLEARING | 16. Normal Clearing | OR2\_CAUSE\_NORMAL\_CLEARING | | gone, success | | AST\_CAUSE\_USER\_BUSY | 17. User busy | OR2\_CAUSE\_BUSY\_NUMBER | 486, 600 | busy | -| AST\_CAUSE\_NO\_USER\_RESPONSE | 18. No user responding |   | 408 | expired | -| AST\_CAUSE\_NO\_ANSWER | 19. No answer from user (user alerted) | OR2\_CAUSE\_NO\_ANSWER | 480, 483 |   | -| AST\_CAUSE\_SUBSCRIBER\_ABSENT | 20. Subscriber absent | OR2\_CAUSE\_UNALLOCATED\_NUMBER |   |   | -| AST\_CAUSE\_CALL\_REJECTED | 21. Call Rejected |   | 401, 403, 407, 603 | cancel, decline | -| AST\_CAUSE\_NUMBER\_CHANGED | 22. Number changed |   | 410 |   | -| AST\_CAUSE\_REDIRECTED\_TO\_NEW\_DESTINATION | 23. Redirected to new destination |   |   |   | -| AST\_CAUSE\_ANSWERED\_ELSEWHERE | 26. Non-selected user clearing(ASTERISK-15057) |   |   |   | -| AST\_CAUSE\_DESTINATION\_OUT\_OF\_ORDER | 27. Destination out of order | OR2\_CAUSE\_OUT\_OF\_ORDER | 502 |   | -| AST\_CAUSE\_INVALID\_NUMBER\_FORMAT | 28. Invalid number format |   | 484 |   | -| AST\_CAUSE\_FACILITY\_REJECTED | 29. Facility rejected |   | 501 |   | -| AST\_CAUSE\_RESPONSE\_TO\_STATUS\_ENQUIRY | 30. Response to STATUS ENQUIRY |   |   |   | -| AST\_CAUSE\_NORMAL\_UNSPECIFIED | 31. Normal, unspecified |   |   |   | -| AST\_CAUSE\_NORMAL\_CIRCUIT\_CONGESTION | 34. No circuit/channel available(Note that we've called this "Circuit/channel congestion" for a while which can cause confusion with code 42) | OR2\_CAUSE\_NETWORK\_CONGESTION |   | general-error | -| AST\_CAUSE\_NETWORK\_OUT\_OF\_ORDER | 38. Network out of order |   | 500 |   | -| AST\_CAUSE\_NORMAL\_TEMPORARY\_FAILURE | 41. Temporary failure |   | 409 |   | -| AST\_CAUSE\_SWITCH\_CONGESTION | 42. Switching equipment congestion |   | 5xx | failed-application | -| AST\_CAUSE\_ACCESS\_INFO\_DISCARDED | 43. Access information discarded |   |   |   | -| AST\_CAUSE\_REQUESTED\_CHAN\_UNAVAIL | 44. Requested circuit/channel not available |   |   |   | -| AST\_CAUSE\_FACILITY\_NOT\_SUBSCRIBED | 50. Requested facility not subscribed |   |   |   | -| AST\_CAUSE\_OUTGOING\_CALL\_BARRED | 52. Outgoing call barred |   |   |   | -| AST\_CAUSE\_INCOMING\_CALL\_BARRED | 54. Incoming call barred |   |   |   | -| AST\_CAUSE\_BEARERCAPABILITY\_NOTAUTH | 57. Bearer capability not authorized |   |   |   | -| AST\_CAUSE\_BEARERCAPABILITY\_NOTAVAIL | 58. Bearer capability not presently available |   | 488, 606 | incompatible-parameters, media-error, unsupported-applications | -| AST\_CAUSE\_BEARERCAPABILITY\_NOTIMPL | 65. Bearer capability not implemented |   |   |   | -| AST\_CAUSE\_CHAN\_NOT\_IMPLEMENTED | 66. Channel type not implemented |   |   |   | -| AST\_CAUSE\_FACILITY\_NOT\_IMPLEMENTED | 69. Requested facility not implemented |   |   | unsupported-transports | -| AST\_CAUSE\_INVALID\_CALL\_REFERENCE | 81. Invalid call reference value |   |   |   | -| AST\_CAUSE\_INCOMPATIBLE\_DESTINATION | 88. Incompatible destination |   |   |   | -| AST\_CAUSE\_INVALID\_MSG\_UNSPECIFIED | 95. Invalid message unspecified |   |   |   | -| AST\_CAUSE\_MANDATORY\_IE\_MISSING | 96. Mandatory information element is missing |   |   |   | -| AST\_CAUSE\_MESSAGE\_TYPE\_NONEXIST | 97. Message type non-existent or not implemented |   |   |   | -| AST\_CAUSE\_WRONG\_MESSAGE | 98. Message not compatible with call state or message type non-existent or not implemented |   |   |   | -| AST\_CAUSE\_IE\_NONEXIST | 99. Information element nonexistent or not implemented |   |   |   | -| AST\_CAUSE\_INVALID\_IE\_CONTENTS | 100. Invalid information element contents |   |   |   | -| AST\_CAUSE\_WRONG\_CALL\_STATE | 101. Message not compatible with call state |   |   |   | -| AST\_CAUSE\_RECOVERY\_ON\_TIMER\_EXPIRE | 102. Recover on timer expiry |   | 504 | timeout | -| AST\_CAUSE\_MANDATORY\_IE\_LENGTH\_ERROR | ? Mandatory IE length error |   |   |   | -| AST\_CAUSE\_PROTOCOL\_ERROR | 111. Protocol error, unspecified |   |   | failed-transport, security-error | -| AST\_CAUSE\_INTERWORKING | 127. Interworking, unspecified |   | 4xx, 505, 6xx | connectivity-error | +| AST\_CAUSE\_NO\_USER\_RESPONSE | 18. No user responding | | 408 | expired | +| AST\_CAUSE\_NO\_ANSWER | 19. No answer from user (user alerted) | OR2\_CAUSE\_NO\_ANSWER | 480, 483 | | +| AST\_CAUSE\_SUBSCRIBER\_ABSENT | 20. Subscriber absent | OR2\_CAUSE\_UNALLOCATED\_NUMBER | | | +| AST\_CAUSE\_CALL\_REJECTED | 21. Call Rejected | | 401, 403, 407, 603 | cancel, decline | +| AST\_CAUSE\_NUMBER\_CHANGED | 22. Number changed | | 410 | | +| AST\_CAUSE\_REDIRECTED\_TO\_NEW\_DESTINATION | 23. Redirected to new destination | | | | +| AST\_CAUSE\_ANSWERED\_ELSEWHERE | 26. Non-selected user clearing(ASTERISK-15057) | | | | +| AST\_CAUSE\_DESTINATION\_OUT\_OF\_ORDER | 27. Destination out of order | OR2\_CAUSE\_OUT\_OF\_ORDER | 502 | | +| AST\_CAUSE\_INVALID\_NUMBER\_FORMAT | 28. Invalid number format | | 484 | | +| AST\_CAUSE\_FACILITY\_REJECTED | 29. Facility rejected | | 501 | | +| AST\_CAUSE\_RESPONSE\_TO\_STATUS\_ENQUIRY | 30. Response to STATUS ENQUIRY | | | | +| AST\_CAUSE\_NORMAL\_UNSPECIFIED | 31. Normal, unspecified | | | | +| AST\_CAUSE\_NORMAL\_CIRCUIT\_CONGESTION | 34. No circuit/channel available(Note that we've called this "Circuit/channel congestion" for a while which can cause confusion with code 42) | OR2\_CAUSE\_NETWORK\_CONGESTION | | general-error | +| AST\_CAUSE\_NETWORK\_OUT\_OF\_ORDER | 38. Network out of order | | 500 | | +| AST\_CAUSE\_NORMAL\_TEMPORARY\_FAILURE | 41. Temporary failure | | 409 | | +| AST\_CAUSE\_SWITCH\_CONGESTION | 42. Switching equipment congestion | | 5xx | failed-application | +| AST\_CAUSE\_ACCESS\_INFO\_DISCARDED | 43. Access information discarded | | | | +| AST\_CAUSE\_REQUESTED\_CHAN\_UNAVAIL | 44. Requested circuit/channel not available | | | | +| AST\_CAUSE\_FACILITY\_NOT\_SUBSCRIBED | 50. Requested facility not subscribed | | | | +| AST\_CAUSE\_OUTGOING\_CALL\_BARRED | 52. Outgoing call barred | | | | +| AST\_CAUSE\_INCOMING\_CALL\_BARRED | 54. Incoming call barred | | | | +| AST\_CAUSE\_BEARERCAPABILITY\_NOTAUTH | 57. Bearer capability not authorized | | | | +| AST\_CAUSE\_BEARERCAPABILITY\_NOTAVAIL | 58. Bearer capability not presently available | | 488, 606 | incompatible-parameters, media-error, unsupported-applications | +| AST\_CAUSE\_BEARERCAPABILITY\_NOTIMPL | 65. Bearer capability not implemented | | | | +| AST\_CAUSE\_CHAN\_NOT\_IMPLEMENTED | 66. Channel type not implemented | | | | +| AST\_CAUSE\_FACILITY\_NOT\_IMPLEMENTED | 69. Requested facility not implemented | | | unsupported-transports | +| AST\_CAUSE\_INVALID\_CALL\_REFERENCE | 81. Invalid call reference value | | | | +| AST\_CAUSE\_INCOMPATIBLE\_DESTINATION | 88. Incompatible destination | | | | +| AST\_CAUSE\_INVALID\_MSG\_UNSPECIFIED | 95. Invalid message unspecified | | | | +| AST\_CAUSE\_MANDATORY\_IE\_MISSING | 96. Mandatory information element is missing | | | | +| AST\_CAUSE\_MESSAGE\_TYPE\_NONEXIST | 97. Message type non-existent or not implemented | | | | +| AST\_CAUSE\_WRONG\_MESSAGE | 98. Message not compatible with call state or message type non-existent or not implemented | | | | +| AST\_CAUSE\_IE\_NONEXIST | 99. Information element nonexistent or not implemented | | | | +| AST\_CAUSE\_INVALID\_IE\_CONTENTS | 100. Invalid information element contents | | | | +| AST\_CAUSE\_WRONG\_CALL\_STATE | 101. Message not compatible with call state | | | | +| AST\_CAUSE\_RECOVERY\_ON\_TIMER\_EXPIRE | 102. Recover on timer expiry | | 504 | timeout | +| AST\_CAUSE\_MANDATORY\_IE\_LENGTH\_ERROR | ? Mandatory IE length error | | | | +| AST\_CAUSE\_PROTOCOL\_ERROR | 111. Protocol error, unspecified | | | failed-transport, security-error | +| AST\_CAUSE\_INTERWORKING | 127. Interworking, unspecified | | 4xx, 505, 6xx | connectivity-error | #### Notes diff --git a/docs/Configuration/Reporting/Call-Detail-Records-CDR/CDR-Specification.md b/docs/Configuration/Reporting/Call-Detail-Records-CDR/CDR-Specification.md index a320cff444..e4fbabdf2b 100644 --- a/docs/Configuration/Reporting/Call-Detail-Records-CDR/CDR-Specification.md +++ b/docs/Configuration/Reporting/Call-Detail-Records-CDR/CDR-Specification.md @@ -3,7 +3,7 @@ title: CDR Specification pageid: 22088359 --- -Call Detail Records, or CDRs, have been around in Asterisk for a long, long time. In fact, portions of it were taken from the `Zapata` library, as noted in `cdr.c`: +Call Detail Records, or CDRs, have been around in Asterisk for a long, long time. In fact, portions of it were taken from the `Zapata` library, as noted in `cdr.c`: ``` * @@ -19,7 +19,7 @@ In Asterisk 12, changes in the bridging architecture necessitated a substantial * The behavior of CDRs between multiple parties is now defined. * Depending on how channels are dialed and bridged, multiple CDRs will be created for a given call. Post-processing of these records **will** be required to determine the overall statistics of the call. -It is important to note that in Asterisk 1.8, Channel Event Logging (CEL) was introduced as an alternative to CDRs. Unlike CDRs, where a relatively few records are produced for a call, CEL provides a sequence of events regarding the state of channels within Asterisk. CELs provide substantially more information about what is occurring to the channels involved in a call, thus allowing an Asterisk user to construct their own billing system by handling the events as they choose. While CEL will never supplant CDRs, they are an option if CDRs do not provide the billing information you need or in the format you require. While improvements have been made and some complex scenarios defined in this specification, the fact that CEL can provide a more robust billing system is still true as of Asterisk 12. +It is important to note that in Asterisk 1.8, Channel Event Logging (CEL) was introduced as an alternative to CDRs. Unlike CDRs, where a relatively few records are produced for a call, CEL provides a sequence of events regarding the state of channels within Asterisk. CELs provide substantially more information about what is occurring to the channels involved in a call, thus allowing an Asterisk user to construct their own billing system by handling the events as they choose. While CEL will never supplant CDRs, they are an option if CDRs do not provide the billing information you need or in the format you require. While improvements have been made and some complex scenarios defined in this specification, the fact that CEL can provide a more robust billing system is still true as of Asterisk 12. Asterisk Users moving from Asterisk 11 and earlier to later versions are highly encouraged to read this specification carefully. @@ -29,7 +29,7 @@ This CDR specification applies to Asterisk 12 and later. It does not cover CDRs Note that this does not include a comprehensive analysis as to how CDRs can be produced in all call scenarios in Asterisk. It defines the behavior for common scenarios, but certain scenarios are deliberately left unspecified. The behavior of CDRs in said scenarios is **undefined and is not a bug.** -It is known that the behavior of CDRs will not allow all applications to capture the billing requirements for their systems. If CDRs cannot meet the requirements of your application, [Channel Event Logging](/Configuration/Reporting/Channel-Event-Logging-CEL) (CEL) provides call information at a much finer granularity, allowing complex billing systems to be constructed. Please see the [Asterisk CEL Specification](/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Specification) for more information on CEL. +It is known that the behavior of CDRs will not allow all applications to capture the billing requirements for their systems. If CDRs cannot meet the requirements of your application, [Channel Event Logging](/Configuration/Reporting/Channel-Event-Logging-CEL) (CEL) provides call information at a much finer granularity, allowing complex billing systems to be constructed. Please see the [Asterisk CEL Specification](/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Specification) for more information on CEL. ## Terminology @@ -44,7 +44,7 @@ It is known that the behavior of CDRs will not allow all applications to capture ## CDR Overview -A CDR is a record of communication between one or two parties. As such, a single CDR always addresses the communication between two parties: a Party A and a Party B. The CDR reflects the view of the call from the perspective of Party A, while Party B is the party that Party A is communicating with. Each CDR includes the following times: +A CDR is a record of communication between one or two parties. As such, a single CDR always addresses the communication between two parties: a Party A and a Party B. The CDR reflects the view of the call from the perspective of Party A, while Party B is the party that Party A is communicating with. Each CDR includes the following times: * Start time - the time at which the CDR was created for Party A * Answer time - the time at which Party A and Party B could begin communicating @@ -93,27 +93,27 @@ A CDR record is created in any one of the following situations: * Whenever a channel leaves a bridge and is not hung up. * When a CDR is forked from a prior record. * When a channel enters a multi-party bridge. -* When a channel [dials more than one channel](#dialing-parties). +* When a channel [dials more than one channel](#dialing-parties). -When it is created, a CDR inherits the `uniqueid` and `linkedid` from its Party A channel, and a new `sequence` number is generated. When created as a result of a dial operation, the channel acting as the caller is always the Party A. +When it is created, a CDR inherits the `uniqueid` and `linkedid` from its Party A channel, and a new `sequence` number is generated. When created as a result of a dial operation, the channel acting as the caller is always the Party A. ##### Dialing Parties -When a channel is known to dial other channels, a CDR is created for each dial attempt. The dial status is recorded for each dial attempt as a [CDR Disposition](#dispositions). Note that not all dial attempts may be dispatched depending on the CDR configuration. The caller is always the Party A in the created CDRs. +When a channel is known to dial other channels, a CDR is created for each dial attempt. The dial status is recorded for each dial attempt as a [CDR Disposition](#dispositions). Note that not all dial attempts may be dispatched depending on the CDR configuration. The caller is always the Party A in the created CDRs. ##### Bridging If a channel is bridged with another channel, the following procedure is performed: * The CDR is marked as having entered a bridge. If there is no other channel in the bridge, the CDR waits for another channel to join. -* For each pairing of channels, the channels are compared to determine which is the Party A channel and which is the Party B channel. (See [Choosing the Party A channel](#choosing-the-party-a-channel)). +* For each pairing of channels, the channels are compared to determine which is the Party A channel and which is the Party B channel. (See [Choosing the Party A channel](#choosing-the-party-a-channel)). + If the channel entering the bridge is the Party A, the CDR has a Party B, and the channel it is bridged with is the Party B, the CDR continues. + If the channel entering the bridge is the Party A, the CDR has a Party B, and the channel is not already the Party B, the current CDR is finalized and a new CDR is created for the relationship between the two parties. Note that the original CDR will be re-activated if the existing Party B enters the bridge. + If the channel entering the bridge is the Party A, the CDR has no Party B, then the channel it is bridged with becomes the Party B. + If the channel entering the bridge is the Party B, the other channel has a CDR with no Party B, this channel becomes the Party B and the existing CDR is finalized. + If the channel entering the bridge is the Party B, the other channel has a CDR with a Party B, and this channel is that CDR's Party B, then the existing CDR is finalized and the other channel's CDR activated. + If the channel entering the bridge is the Party B, the other channel has a CDR with a Party B, and this channel is not that CDR's Party B, then the existing CDR is finalized and a new CDR is created for that other channel with this channel as the Party B. -* If a third party joins the bridge with Party A and Party B, the process [Choosing the Party A channel](#choosing-the-party-a-channel) is repeated for each pairing of channels. Thus, in a three-way call there will be three CDR records; in a four-way call there will be six records, etc. +* If a third party joins the bridge with Party A and Party B, the process [Choosing the Party A channel](#choosing-the-party-a-channel) is repeated for each pairing of channels. Thus, in a three-way call there will be three CDR records; in a four-way call there will be six records, etc. !!! tip This feels complex, but there's really two rules going on here: @@ -132,9 +132,9 @@ A CDR is finalized in one of the following scenarios: When a CDR is finalized, no further modifications can be made to the CDR by the user or Asterisk. -If a Party A channel in a CDR is not hung up but the CDR is finalized - such as when the channel leaves a bridge of its Party B hangs up - a new CDR is made for that channel and the process in [CDR Creation](#creation) is begun again. Note that if the Party B in a CDR continues on in the the dialplan and/or is bridged with a new party, it may become Party A for a new CDR. +If a Party A channel in a CDR is not hung up but the CDR is finalized - such as when the channel leaves a bridge of its Party B hangs up - a new CDR is made for that channel and the process in [CDR Creation](#creation) is begun again. Note that if the Party B in a CDR continues on in the the dialplan and/or is bridged with a new party, it may become Party A for a new CDR. -If at any point the Party A channel for a CDR is hung up, all CDR records for that Party A are [dispatched](#dispatch). +If at any point the Party A channel for a CDR is hung up, all CDR records for that Party A are [dispatched](#dispatch). ##### Dispatch @@ -145,10 +145,10 @@ When a CDR is dispatched, all CDRs associated with the channel are committed to Asterisk does not have the concept of "internal" versus "external" devices. As such, what constitutes the Party A channel is highly dependent on a particular system configuration which is outside the control of the CDR system. As such, choosing a Party A uses the following rules: 1. If the channel was dialed (but not originated), the channel is always Party B. -2. If one of the two channels has the `party_a` flag set, then that channel is chosen as the Party A. -3. If neither or both channels have the `party_A` flag, the channel with the oldest creation time is chosen as the Party A. +2. If one of the two channels has the `party_a` flag set, then that channel is chosen as the Party A. +3. If neither or both channels have the `party_A` flag, the channel with the oldest creation time is chosen as the Party A. -The `party_A` flag may be set using the [CDR function](/Latest_API/API_Documentation/Dialplan_Functions/CDR). +The `party_A` flag may be set using the [CDR function](/Latest_API/API_Documentation/Dialplan_Functions/CDR). #### LinkedID Propagation @@ -230,7 +230,7 @@ Alice calls into Asterisk at extension 500 using a SIP phone and, during dialpla | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 500 | default | SIP/alice-00000000 |   | NoOp |   | 2013-03-04 13:11:18 |   | 2013-03-04 13:11:20 | 2 | 0 | NO ANSWER | DOCUMENTATION | 100 |   | Asterisk-01-1362424276.2 |   | 34 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 500 | default | SIP/alice-00000000 | | NoOp | | 2013-03-04 13:11:18 | | 2013-03-04 13:11:20 | 2 | 0 | NO ANSWER | DOCUMENTATION | 100 | | Asterisk-01-1362424276.2 | | 34 | Asterisk-01-1362424276.2 | ### Unanswered "Outbound" Call @@ -238,7 +238,7 @@ Asterisk creates a call file to dial Alice and playback tt-monkeys to her. Alice | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -|   |   | s | default | SIP/alice-00000000 |   | AppDial | SIP/Alice | 2013-03-04 13:11:18 |   | 2013-03-04 13:11:20 | 2 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 4 | Asterisk-01-1362424276.2 | +| | | s | default | SIP/alice-00000000 | | AppDial | SIP/Alice | 2013-03-04 13:11:18 | | 2013-03-04 13:11:20 | 2 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 4 | Asterisk-01-1362424276.2 | ### Single Party @@ -246,7 +246,7 @@ Alice calls into Asterisk's VoiceMailMain application. This implicitly Answers t | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 8500 | default | SIP/alice-00000000 |   | Hangup |   | 2013-03-04 13:11:18 | 2013-03-04 13:11:20 | 2013-03-04 13:12:18 | 60 | 58 | ANSWERED | DOCUMENTATION | 100 |   | Asterisk-01-1362424276.2 |   | 112 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 8500 | default | SIP/alice-00000000 | | Hangup | | 2013-03-04 13:11:18 | 2013-03-04 13:11:20 | 2013-03-04 13:12:18 | 60 | 58 | ANSWERED | DOCUMENTATION | 100 | | Asterisk-01-1362424276.2 | | 112 | Asterisk-01-1362424276.2 | ### Basic Two Party Calls @@ -258,7 +258,7 @@ Alice calls into Asterisk, which dials Bob. Bob Answers, and a bridge is formed | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:26 | 2013-03-04 13:13:18 | 120 | 112 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 12 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:26 | 2013-03-04 13:13:18 | 120 | 112 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 12 | Asterisk-01-1362424276.2 | #### Unanswered Dial @@ -266,7 +266,7 @@ Alice calls into Asterisk, which dials Bob. Bob refuses to pick up his phone, an | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,10,Tt | 2013-03-04 13:11:18 |   | 2013-03-04 13:11:28 | 10 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 1 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,10,Tt | 2013-03-04 13:11:18 | | 2013-03-04 13:11:28 | 10 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 1 | Asterisk-01-1362424276.2 | #### Parallel Dial @@ -274,8 +274,8 @@ Alice calls into Asterisk, which dials Bob's SIP desk phone as well as his IAX2 | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob&IAX2/bob,,Tt | 2013-03-04 13:11:18 |   | 2013-03-04 13:11:28 | 10 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 12 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | IAX2/bob-00000000 | Dial | SIP/bob&IAX2/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:28 | 70 | 60 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 13 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob&IAX2/bob,,Tt | 2013-03-04 13:11:18 | | 2013-03-04 13:11:28 | 10 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 12 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | IAX2/bob-00000000 | Dial | SIP/bob&IAX2/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:28 | 70 | 60 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 13 | Asterisk-01-1362424276.2 | #### Call Forward @@ -291,8 +291,8 @@ Alice calls into Asterisk, which dials Bob's SIP phone. Bob answers, and Alice a | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:11:48 | 30 | 20 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:53 | 65 | 60 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:11:48 | 30 | 20 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:53 | 65 | 60 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 102 | Asterisk-01-1362424276.2 | #### Core Attended Transfer to Channel @@ -300,9 +300,9 @@ Alice calls into Asterisk, which dials Bob's SIP phone. Bob answers, and Alice a | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:18 | 30 | 26 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 102 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/bob,,Tt | 2013-03-04 13:12:18 | 2013-03-04 13:12:18 | 2013-03-04 13:12:53 | 45 | 45 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 103 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:18 | 30 | 26 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/bob,,Tt | 2013-03-04 13:12:18 | 2013-03-04 13:12:18 | 2013-03-04 13:12:53 | 45 | 45 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 103 | Asterisk-01-1362424276.2 | !!! note In the example above, note the following: @@ -318,9 +318,9 @@ Alice calls into Asterisk, which dials Bob's SIP phone. Bob answers, and Alice a | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 8500 | default | SIP/bob-00000001 |   | VoiceMail | 300 | 2013-03-04 13:11:48 | 2013-03-04 13:11:49 | 2013-03-04 13:12:18 | 30 | 29 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 102 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 8500 | default | SIP/alice-00000000 |   | VoiceMail | 300 | 2013-03-04 13:12:18 | 2013-03-04 13:12:18 | 2013-03-04 13:13:18 | 60 | 60 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 103 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 8500 | default | SIP/bob-00000001 | | VoiceMail | 300 | 2013-03-04 13:11:48 | 2013-03-04 13:11:49 | 2013-03-04 13:12:18 | 30 | 29 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 8500 | default | SIP/alice-00000000 | | VoiceMail | 300 | 2013-03-04 13:12:18 | 2013-03-04 13:12:18 | 2013-03-04 13:13:18 | 60 | 60 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 103 | Asterisk-01-1362424276.2 | #### SIP Protocol Attended Transfer @@ -338,9 +338,9 @@ Alice calls into Asterisk, which dials Bob's SIP phone. Bob answers, and Alice a | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 |   | 2013-03-04 13:11:50 | 2 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 102 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:50 | 2013-03-04 13:11:55 | 2013-03-04 13:12:30 | 40 | 35 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 103 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | | 2013-03-04 13:11:50 | 2 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:50 | 2013-03-04 13:11:55 | 2013-03-04 13:12:30 | 40 | 35 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 103 | Asterisk-01-1362424276.2 | #### Three Way Call @@ -348,10 +348,10 @@ Alice calls into Asterisk, which dials Bob's SIP phone. Bob answers, and Alice a | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:13:18 | 120 | 110 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:08 | 20 | 15 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 102 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/bob,,Tt | 2013-03-04 13:12:08 | 2013-03-04 13:12:08 | 2013-03-04 13:13:18 | 70 | 70 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 103 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:12:08 | 2013-03-04 13:12:08 | 2013-03-04 13:13:18 | 70 | 70 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 104 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:13:18 | 120 | 110 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:08 | 20 | 15 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Dial | SIP/bob,,Tt | 2013-03-04 13:12:08 | 2013-03-04 13:12:08 | 2013-03-04 13:13:18 | 70 | 70 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 103 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 300 | default | SIP/bob-00000001 | SIP/charlie-00000002 | Dial | SIP/charlie,,Tt | 2013-03-04 13:12:08 | 2013-03-04 13:12:08 | 2013-03-04 13:13:18 | 70 | 70 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 104 | Asterisk-01-1362424276.2 | !!! note In the example above, note the following: @@ -365,9 +365,9 @@ Alice calls into Asterisk, which dials Bob's SIP phone. Bob answers, and Alice a | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 300 | default | SIP/bob-00000002 | SIP/charlie-00000003 | Dial | SIP/charlie | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:08 | 20 | 15 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 102 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/charlie-00000003 | Dial | SIP/bob | 2013-03-04 13:12:18 | 2013-03-04 13:12:18 | 2013-03-04 13:12:28 | 10 | 10 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 103 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 300 | default | SIP/bob-00000002 | SIP/charlie-00000003 | Dial | SIP/charlie | 2013-03-04 13:11:48 | 2013-03-04 13:11:53 | 2013-03-04 13:12:08 | 20 | 15 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/charlie-00000003 | Dial | SIP/bob | 2013-03-04 13:12:18 | 2013-03-04 13:12:18 | 2013-03-04 13:12:28 | 10 | 10 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 103 | Asterisk-01-1362424276.2 | !!! note The important point to note here is that a SIP attended transfer uses two channels to communicate with Bob - `SIP/bob-00000001` and `SIP/bob-00000002`. The CDR records are associated by virtue of the `linkedid` field. @@ -389,8 +389,8 @@ An external application [Originates](/Latest_API/API_Documentation/AMI_Actions/O | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "" | dial\_alice | 100 | default | Local/dial\_alice@default-00000001;1 | SIP/alice-00000002 | Dial | SIP/alice,,tT | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424290.1 |   | 101 | Asterisk-01-1362424290.1 | -| "" | voicemail |   | default | Local/dial\_alice@default-00000001;2 |   | VoiceMailMain | 100 | 2013-03-04 13:11:28 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 50 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424290.1 |   | 102 | Asterisk-01-1362424290.1 | +| "" | dial\_alice | 100 | default | Local/dial\_alice@default-00000001;1 | SIP/alice-00000002 | Dial | SIP/alice,,tT | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424290.1 | | 101 | Asterisk-01-1362424290.1 | +| "" | voicemail | | default | Local/dial\_alice@default-00000001;2 | | VoiceMailMain | 100 | 2013-03-04 13:11:28 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 50 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424290.1 | | 102 | Asterisk-01-1362424290.1 | ##### Local channel between bridges @@ -398,8 +398,8 @@ An external application [Originates](/Latest_API/API_Documentation/AMI_Actions/O | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "" | dial\_alice | 100 | default | Local/dial\_alice@default-00000001;1 | SIP/alice-00000002 | Dial | SIP/alice,,tT | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424290.1 |   | 101 | Asterisk-01-1362424290.1 | -| "" | dial\_bob | 200 | default | Local/dial\_alice@default-00000001;2 | SIP/bob-00000003 | Dial | SIP/bob,,tT | 2013-03-04 13:11:28 | 2013-03-04 13:11:38 | 2013-03-04 13:12:18 | 50 | 40 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424290.1 |   | 102 | Asterisk-01-1362424290.1 | +| "" | dial\_alice | 100 | default | Local/dial\_alice@default-00000001;1 | SIP/alice-00000002 | Dial | SIP/alice,,tT | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 60 | 50 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424290.1 | | 101 | Asterisk-01-1362424290.1 | +| "" | dial\_bob | 200 | default | Local/dial\_alice@default-00000001;2 | SIP/bob-00000003 | Dial | SIP/bob,,tT | 2013-03-04 13:11:28 | 2013-03-04 13:11:38 | 2013-03-04 13:12:18 | 50 | 40 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424290.1 | | 102 | Asterisk-01-1362424290.1 | #### Local Channel Optimization @@ -421,9 +421,9 @@ Alice calls into Asterisk and Bob answers. Alice says she wants to talk to Charl | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:11:38 | 20 | 10 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 |   | Park | 60000,default,200,1 | 2013-03-04 13:11:38 | 2013-03-04 13:11:38 | 2013-03-04 13:12:38 | 60 | 60 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 102 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Park | 60000,default,200,1 | 2013-03-04 13:12:38 | 2013-03-04 13:12:38 | 2013-03-04 13:13:38 | 60 | 60 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 103 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:11:38 | 20 | 10 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | | Park | 60000,default,200,1 | 2013-03-04 13:11:38 | 2013-03-04 13:11:38 | 2013-03-04 13:12:38 | 60 | 60 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 300 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Park | 60000,default,200,1 | 2013-03-04 13:12:38 | 2013-03-04 13:12:38 | 2013-03-04 13:13:38 | 60 | 60 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 103 | Asterisk-01-1362424276.2 | ### Call Queues @@ -433,8 +433,8 @@ Alice calls into Asterisk and enters [Queue](/Latest_API/API_Documentation/Dialp | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/bob-00000001 | Queue | complaints | 2013-03-04 13:11:18 |   | 2013-03-04 13:14:18 | 180 | 0 | BUSY | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Queue | complaints | 2013-03-04 13:11:18 | 2013-03-04 13:12:18 | 2013-03-04 13:14:18 | 180 | 120 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/bob-00000001 | Queue | complaints | 2013-03-04 13:11:18 | | 2013-03-04 13:14:18 | 180 | 0 | BUSY | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Queue | complaints | 2013-03-04 13:11:18 | 2013-03-04 13:12:18 | 2013-03-04 13:14:18 | 180 | 120 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 102 | Asterisk-01-1362424276.2 | #### Call Queue - Example 2 @@ -442,8 +442,8 @@ Alice calls into Asterisk and enters Queue without being Answered. She waits in | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/bob-00000001 | Queue | complaints | 2013-03-04 13:11:18 |   | 2013-03-04 13:14:18 | 180 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 101 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Queue | complaints | 2013-03-04 13:11:18 | 2013-03-04 13:12:38 | 2013-03-04 13:14:18 | 180 | 100 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 102 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/bob-00000001 | Queue | complaints | 2013-03-04 13:11:18 | | 2013-03-04 13:14:18 | 180 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 101 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 800 | default | SIP/alice-00000000 | SIP/charlie-00000002 | Queue | complaints | 2013-03-04 13:11:18 | 2013-03-04 13:12:38 | 2013-03-04 13:14:18 | 180 | 100 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 102 | Asterisk-01-1362424276.2 | ### Conference Call @@ -451,9 +451,9 @@ Alice calls into Asterisk and joins a ConfBridge conference. Bob does a bit late | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 1000 | default | SIP/alice-00000000 | SIP/bob-00000001 | ConfBridge | 1000,public\_bridge,public\_user,public\_menu | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:14:18 | 180 | 170 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 1 | Asterisk-01-1362424276.2 | -| "Bob <200>" | 200 | 1000 | default | SIP/bob-00000001 | SIP/charlie-00000002 | ConfBridge | 1000,public\_bridge,public\_user,public\_menu | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 2013-03-04 13:14:18 | 170 | 120 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 2 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 1000 | default | SIP/alice-00000000 | SIP/charlie-00000002 | ConfBridge | 1000,public\_bridge,public\_user,public\_menu | 2013-03-04 13:11:18 | 2013-03-04 13:12:18 | 2013-03-04 13:15:18 | 240 | 180 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 3 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 1000 | default | SIP/alice-00000000 | SIP/bob-00000001 | ConfBridge | 1000,public\_bridge,public\_user,public\_menu | 2013-03-04 13:11:18 | 2013-03-04 13:11:28 | 2013-03-04 13:14:18 | 180 | 170 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 1 | Asterisk-01-1362424276.2 | +| "Bob <200>" | 200 | 1000 | default | SIP/bob-00000001 | SIP/charlie-00000002 | ConfBridge | 1000,public\_bridge,public\_user,public\_menu | 2013-03-04 13:11:28 | 2013-03-04 13:12:18 | 2013-03-04 13:14:18 | 170 | 120 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 2 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 1000 | default | SIP/alice-00000000 | SIP/charlie-00000002 | ConfBridge | 1000,public\_bridge,public\_user,public\_menu | 2013-03-04 13:11:18 | 2013-03-04 13:12:18 | 2013-03-04 13:15:18 | 240 | 180 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 3 | Asterisk-01-1362424276.2 | ### A Complex Example @@ -463,16 +463,16 @@ Alice calls into Asterisk and Dials Bob. Bob answers, and he and Alice talk for | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:00:00 | 2013-03-04 13:00:05 | 2013-03-04 13:01:00 | 60 | 55 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 1 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 200 | default | SIP/alice-00000000 | SIP/bob-00000001 | Dial | SIP/bob,,Tt | 2013-03-04 13:00:00 | 2013-03-04 13:00:05 | 2013-03-04 13:01:00 | 60 | 55 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 1 | Asterisk-01-1362424276.2 | * Bob realizes Alice wants to talk to Sales, so he blind transfers her off to the Sales Queue. Alice enters into the Sales Queue, where she waits for a bit while agents David and Frank are dialed using Local channels to SIP devices. Alice is eventually Answered by David, a sales agent. | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | Local/member1@default-00000001;1 | Queue | sales | 2013-03-04 13:01:00 |   | 2013-03-04 13:02:00 | 60 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 2 | Asterisk-01-1362424276.2 | -|   | 700 | member1 | default | Local/member1@default-00000001;2 | SIP/frank-00000002 | Dial | SIP/frank | 2013-03-04 13:01:50 |   | 2013-03-04 13:02:00 | 10 | 0 | NO ANSWER | DOCUMENTATION |   |   | Asterisk-01-1362424280.1 |   | 3 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | Local/member2@default-00000002;1 | Queue | sales | 2013-03-04 13:01:00 | 2013-03-04 13:02:00 | 2013-03-04 13:05:00 | 240 | 180 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 4 | Asterisk-01-1362424276.2 | -|   | 700 | member2 | default | Local/member2@default-00000002;2 | SIP/david-00000003 | Dial | SIP/david | 2013-03-04 13:02:00 | 2013-03-04 13:02:05 | 2013-03-04 13:06:00 | 240 | 235 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.3 |   | 5 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | Local/member1@default-00000001;1 | Queue | sales | 2013-03-04 13:01:00 | | 2013-03-04 13:02:00 | 60 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 2 | Asterisk-01-1362424276.2 | +| | 700 | member1 | default | Local/member1@default-00000001;2 | SIP/frank-00000002 | Dial | SIP/frank | 2013-03-04 13:01:50 | | 2013-03-04 13:02:00 | 10 | 0 | NO ANSWER | DOCUMENTATION | | | Asterisk-01-1362424280.1 | | 3 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | Local/member2@default-00000002;1 | Queue | sales | 2013-03-04 13:01:00 | 2013-03-04 13:02:00 | 2013-03-04 13:05:00 | 240 | 180 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 4 | Asterisk-01-1362424276.2 | +| | 700 | member2 | default | Local/member2@default-00000002;2 | SIP/david-00000003 | Dial | SIP/david | 2013-03-04 13:02:00 | 2013-03-04 13:02:05 | 2013-03-04 13:06:00 | 240 | 235 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.3 | | 5 | Asterisk-01-1362424276.2 | !!! note Note that with non-optimizing Local channels, the duration of the Alice to the Local channel (which in turns passes media to/from David) may not reflect the length of time that the Local channel to David is in the bridge. As we'll see, additional channels joining the bridge will change that CDR's durations. @@ -481,15 +481,15 @@ Alice calls into Asterisk and Dials Bob. Bob answers, and he and Alice talk for | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Bob <200>" | 200 | 300 | default | SIP/bob-00000004 | SIP/charlie-00000005 | Dial | SIP/charlie,,Tt | 2013-03-04 13:01:10 | 2013-03-04 13:01:20 | 2013-03-04 13:03:20 | 130 | 120 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424277.1 |   | 6 | Asterisk-01-1362424277.1 | +| "Bob <200>" | 200 | 300 | default | SIP/bob-00000004 | SIP/charlie-00000005 | Dial | SIP/charlie,,Tt | 2013-03-04 13:01:10 | 2013-03-04 13:01:20 | 2013-03-04 13:03:20 | 130 | 120 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424277.1 | | 6 | Asterisk-01-1362424277.1 | * David and Alice talk for a bit, but David isn't able to sell her on their new fantastic product, so he puts Alice on hold for a bit and calls Ellen from engineering. Ellen agrees to be on the call, and Alice, David, and Ellen are put into a three-way call. | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "David <900>" | 900 | 901 | default | SIP/david-00000003 | SIP/ellen-00000006 | Dial | SIP/ellen,,Tt | 2013-03-04 13:02:30 | 2013-03-04 13:02:40 | 2013-03-04 13:03:00 | 30 | 20 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424300.1 |   | 7 | Asterisk-01-1362424276.2 | -| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | SIP/ellen-00000006 | Queue | sales | 2013-03-04 13:03:00 | 2013-03-04 13:03:00 | 2013-03-04 13:05:00 | 120 | 120 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 8 | Asterisk-01-1362424276.2 | -|   | 700 | member2 | default | Local/member2@default-00000002;2 | SIP/ellen-00000006 | Dial | SIP/david | 2013-03-04 13:03:00 | 2013-03-04 13:03:00 | 2013-03-04 13:05:00 | 120 | 120 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424280.3 |   | 9 | Asterisk-01-1362424276.2 | +| "David <900>" | 900 | 901 | default | SIP/david-00000003 | SIP/ellen-00000006 | Dial | SIP/ellen,,Tt | 2013-03-04 13:02:30 | 2013-03-04 13:02:40 | 2013-03-04 13:03:00 | 30 | 20 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424300.1 | | 7 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | SIP/ellen-00000006 | Queue | sales | 2013-03-04 13:03:00 | 2013-03-04 13:03:00 | 2013-03-04 13:05:00 | 120 | 120 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 8 | Asterisk-01-1362424276.2 | +| | 700 | member2 | default | Local/member2@default-00000002;2 | SIP/ellen-00000006 | Dial | SIP/david | 2013-03-04 13:03:00 | 2013-03-04 13:03:00 | 2013-03-04 13:05:00 | 120 | 120 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424280.3 | | 9 | Asterisk-01-1362424276.2 | !!! note During the consultation period, David's SIP channel directly Dials Ellen's SIP device. However, when Ellen joins the bridge with David, it is the Local channel to David that is in the bridge, not David's SIP channel. Thus, the CDR reflects the Local channel to Ellen's SIP channel. @@ -498,9 +498,9 @@ Alice calls into Asterisk and Dials Bob. Bob answers, and he and Alice talk for | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | start | answer | end | duration | billsec | disposition | amaflags | accountcode | peeraccount | uniqueid | userfield | sequence | linkedid | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | SIP/charlie-00000005 | Queue | sales | 2013-03-04 13:03:20 | 2013-03-04 13:03:20 | 2013-03-04 13:05:00 | 100 | 100 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424276.2 |   | 10 | Asterisk-01-1362424276.2 | -| "Charlie <300>" | 300 | 701 | default | SIP/charlie-00000005 | Local/member2@default-00000002;2 | Bridge | SIP/alice-00000000 | 2013-03-04 13:03:20 | 2013-03-04 13:03:20 | 2013-03-04 13:06:00 | 160 | 160 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424278.1 |   | 11 | Asterisk-01-1362424276.2 | -| "Charlie <300>" | 300 | 701 | default | SIP/charlie-00000005 | SIP/ellen-00000006 | Bridge | SIP/alice-00000000 | 2013-03-04 13:03:20 | 2013-03-4 13:03:20 | 2013-03-04 13:05:05 | 105 | 105 | ANSWERED | DOCUMENTATION |   |   | Asterisk-01-1362424278.1 |   | 12 | Asterisk-01-1362424276.2 | +| "Alice <100>" | 100 | 700 | default | SIP/alice-00000000 | SIP/charlie-00000005 | Queue | sales | 2013-03-04 13:03:20 | 2013-03-04 13:03:20 | 2013-03-04 13:05:00 | 100 | 100 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424276.2 | | 10 | Asterisk-01-1362424276.2 | +| "Charlie <300>" | 300 | 701 | default | SIP/charlie-00000005 | Local/member2@default-00000002;2 | Bridge | SIP/alice-00000000 | 2013-03-04 13:03:20 | 2013-03-04 13:03:20 | 2013-03-04 13:06:00 | 160 | 160 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424278.1 | | 11 | Asterisk-01-1362424276.2 | +| "Charlie <300>" | 300 | 701 | default | SIP/charlie-00000005 | SIP/ellen-00000006 | Bridge | SIP/alice-00000000 | 2013-03-04 13:03:20 | 2013-03-4 13:03:20 | 2013-03-04 13:05:05 | 105 | 105 | ANSWERED | DOCUMENTATION | | | Asterisk-01-1362424278.1 | | 12 | Asterisk-01-1362424276.2 | !!! note Because Charlie's channel is older then either the Local channel to David's SIP channel or Ellen's SIP channel, Charlie is chosen as Party A for those CDRs. Alice, on the other hand, is older than Charlie, so she is Party A for that CDR. Because Alice is the oldest channel, her `linkedid` is propagated to all CDRs in the bridge. However, the CDR between Charlie and Bob is not affected, as Bob is the Party A in that CDR and the CDR would already have been dispatched by the time Charlie joined this bridge. diff --git a/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Configuration-Examples/MSSQL-CEL-Backend.md b/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Configuration-Examples/MSSQL-CEL-Backend.md index 70ab422cc6..e1a85e8de3 100644 --- a/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Configuration-Examples/MSSQL-CEL-Backend.md +++ b/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Configuration-Examples/MSSQL-CEL-Backend.md @@ -156,7 +156,7 @@ make clean && ./configure --with-tds && make update && make && make install [ -f /etc/asterisk/cel_odbc.conf ] > /etc/asterisk/cel_odbc.conf ``` -### Setup cel_tds configuration files. +### Set up cel_tds configuration files. These are working samples from my system. You will need to modify for your setup. Define your usernames and passwords here, secure file as well. diff --git a/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Specification.md b/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Specification.md index 562671e89e..255b3286f1 100644 --- a/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Specification.md +++ b/docs/Configuration/Reporting/Channel-Event-Logging-CEL/CEL-Specification.md @@ -7,12 +7,12 @@ pageid: 25919712 ## Introduction -Channel Event Logging (CEL) provides a series of records describing the state of channels in Asterisk to any of several [event recording back-ends](../CEL-Configuration-Examples). CEL records provide substantially more information than CDRs and thus allow an Asterisk User to construct their own more complex billing system. +Channel Event Logging (CEL) provides a series of records describing the state of channels in Asterisk to any of several [event recording back-ends](../CEL-Configuration-Examples). CEL records provide substantially more information than CDRs and thus allow an Asterisk User to construct their own more complex billing system. As a result of the bridging work done for Asterisk 12, CEL behavior has changed for several events that occur in the system. The most significant changes are: * AST\_CEL\_BRIDGE\_ENTER and AST\_CEL\_BRIDGE\_EXIT have been introduced to denote participant changes in bridges. -* AST\_CEL\_BRIDGE\_START and AST\_CEL\_BRIDGE\_END have been removed as they no longer applies to the new bridging framework. +* AST\_CEL\_BRIDGE\_START and AST\_CEL\_BRIDGE\_END have been removed as they no longer applies to the new bridging framework. * AST\_CEL\_BRIDGE\_UPDATE has been removed as it no longer applies to the new bridging framework. * AST\_CEL\_LOCAL\_OPTIMIZE has been added to describe local channel optimizations that occur. * All linkedid accounting and record generation is now handled within the CEL engine. @@ -32,7 +32,7 @@ This CEL specification applies to Asterisk 12 and above. While some portions of | Stasis | The internal message bus in Asterisk that conveys state to the CEL engine. | | Primary | The channel around which a CEL record is focused. | | AMI | Asterisk Manager Interface | -| CSV | Comma Separated Values.  A format commonly used for tabular data when stored outside of a database. | +| CSV | Comma Separated Values. A format commonly used for tabular data when stored outside of a database. | ## CEL Overview @@ -86,17 +86,17 @@ An AST\_CEL\_LINKEDID\_END record is generated when the last channel using the g These records convey the Primary's interactions with other channels or bridges. -#### Bridge Enter +#### Bridge Enter -An AST\_CEL\_BRIDGE\_ENTER record is generated when a channel enters a bridge. The entering channel is the Primary for this event. Additional information is conveyed in the extra field under the "bridge\_id" key. The "bridge\_technology" key is available in Asterisk 13+. All other channels in the bridge at the time of entry are available in the peer field as a comma-separated list. +An AST\_CEL\_BRIDGE\_ENTER record is generated when a channel enters a bridge. The entering channel is the Primary for this event. Additional information is conveyed in the extra field under the "bridge\_id" key. The "bridge\_technology" key is available in Asterisk 13+. All other channels in the bridge at the time of entry are available in the peer field as a comma-separated list. #### Bridge Exit -An AST\_CEL\_BRIDGE\_EXIT record is generated when a channel exits a bridge. The leaving channel is the Primary for this event. Additional information is conveyed in the extra field under the "bridge\_id" key. The "bridge\_technology" key is available in Asterisk 13+. All other channels in the bridge at the time of exit are available in the peer field as a comma-separated list. +An AST\_CEL\_BRIDGE\_EXIT record is generated when a channel exits a bridge. The leaving channel is the Primary for this event. Additional information is conveyed in the extra field under the "bridge\_id" key. The "bridge\_technology" key is available in Asterisk 13+. All other channels in the bridge at the time of exit are available in the peer field as a comma-separated list. #### Forward -An AST\_CEL\_FORWARD record is generated when a dialing channel is forwarded elsewhere by a dialed channel. The dialing channel is the Primary for this event. Additional information is conveyed in the extra field under the "forward" key. +An AST\_CEL\_FORWARD record is generated when a dialing channel is forwarded elsewhere by a dialed channel. The dialing channel is the Primary for this event. Additional information is conveyed in the extra field under the "forward" key. #### Park Start @@ -104,11 +104,11 @@ An AST\_CEL\_PARK\_START record is generated when a channel is parked. The parke #### Park End -An AST\_CEL\_PARK\_START record is generated when a channel is unparked. The unparked channel is the Primary for this event. Additional information is conveyed in the extra field under the "reason" key and the "retriever" key when available. This record always occurs after its corresponding AST\_CEL\_PARK\_START. +An AST\_CEL\_PARK\_START record is generated when a channel is unparked. The unparked channel is the Primary for this event. Additional information is conveyed in the extra field under the "reason" key and the "retriever" key when available. This record always occurs after its corresponding AST\_CEL\_PARK\_START. #### Pickup -An AST\_CEL\_PICKUP record is generated when a channel is picked up. The picked up channel (also known as the target) is the Primary for this record. The name of the channel that is picking up is conveyed in the extra field under the "pickup\_channel" key. +An AST\_CEL\_PICKUP record is generated when a channel is picked up. The picked up channel (also known as the target) is the Primary for this record. The name of the channel that is picking up is conveyed in the extra field under the "pickup\_channel" key. ### Meta-Records @@ -116,7 +116,7 @@ These records convey additional context relating to surrounding CEL records #### Blind Transfer -An AST\_CEL\_BLINDTRANSFER record is generated when a blind transfer feature is activated on a bridge. The initiating channel is the Primary for this record. Additional information is conveyed in the extra field under the "extension", "context", and "bridge\_id" keys. +An AST\_CEL\_BLINDTRANSFER record is generated when a blind transfer feature is activated on a bridge. The initiating channel is the Primary for this record. Additional information is conveyed in the extra field under the "extension", "context", and "bridge\_id" keys. #### Attended Transfer @@ -124,13 +124,13 @@ An AST\_CEL\_ATTENDEDTRANSFER record is generated when an attended transfer is s ##### Bridge-Bridge Attended Transfers -This type of attended transfer occurs when both involved channels are bridged. The initiating channel is the Primary for this record. Additional information is conveyed in the extra field under the "bridge1\_id", "channel2\_name", "bridge2\_id", "transferee\_channel\_name", and "transfer\_target\_channel\_name" keys. +This type of attended transfer occurs when both involved channels are bridged. The initiating channel is the Primary for this record. Additional information is conveyed in the extra field under the "bridge1\_id", "channel2\_name", "bridge2\_id", "transferee\_channel\_name", and "transfer\_target\_channel\_name" keys. The records associated with this type of transfer will vary depending on the configuration of the bridges involved and the number of channels involved. Possible methods of accomplishing the transfer include (but are not limited to) channel swap, bridge merge, and bridge link via a local channel. ##### Bridge-App Attended Transfers -This type of attended transfer occurs when one involved channel is bridged while the other is running an application. The bridged channel is the Primary for this record. Additional information is conveyed in the extra field under the "bridge1\_id", "channel2\_name", and "app" keys. +This type of attended transfer occurs when one involved channel is bridged while the other is running an application. The bridged channel is the Primary for this record. Additional information is conveyed in the extra field under the "bridge1\_id", "channel2\_name", and "app" keys. ##### App-App Attended Transfers @@ -207,15 +207,15 @@ The ODBC CEL output module provides logging capability to any ODBC-compatible da ### PGSQL -The PGSQL CEL output module provides logging capability to PostgreSQL databases when it is desirable to avoid the ODBC abstraction layer. This module is configured in cel\_pgsql.conf. +The PGSQL CEL output module provides logging capability to PostgreSQL databases when it is desirable to avoid the ODBC abstraction layer. This module is configured in cel\_pgsql.conf. ### RADIUS -The RADIUS CEL output module allows the CEL engine to publish records to a RADIUS server. This module is configured in cel.conf in the [radius] section. +The RADIUS CEL output module allows the CEL engine to publish records to a RADIUS server. This module is configured in cel.conf in the [radius] section. ### SQLite -The SQLite CEL output module provides logging capability to a SQLite3 database in a format described in its configuration file. This module is configured in cel\_sqlite3\_custom.conf. +The SQLite CEL output module provides logging capability to a SQLite3 database in a format described in its configuration file. This module is configured in cel\_sqlite3\_custom.conf. ### TDS @@ -232,7 +232,7 @@ For the following scenarios, assume the CEL engine is configured to generate the ### Two-Participant Bridge -The following scenario demonstrates channel creation, channel destruction, bridge start, and bridge end: +The following scenario demonstrates channel creation, channel destruction, bridge start, and bridge end: | Event | Record | Primary | Extra | | --- | --- | --- | --- | @@ -248,7 +248,7 @@ The following scenario demonstrates channel creation, channel destruction, brid ### Multi-participant Conference -The following scenario demonstrates conversion of a bridge to a multi-participant conference: +The following scenario demonstrates conversion of a bridge to a multi-participant conference: | Event | Record | Primary | Extra | | --- | --- | --- | --- | @@ -302,7 +302,7 @@ For this scenario, assume that AST\_CEL\_ANSWER, AST\_CEL\_HANGUP, AST\_CEL\_APP | Channel Alice is created | AST\_CEL\_CHANNEL\_START | Alice | | | Alice executes Dial(SIP/Bob) | AST\_CEL\_APP\_START | Alice | | | Channel Bob is created | AST\_CEL\_CHANNEL\_START | Bob | | -| Bob responds BUSY | AST\_CEL\_HANGUP | Bob |  {"hangupcause":21,"dialstatus":"","hangupsource":""} | +| Bob responds BUSY | AST\_CEL\_HANGUP | Bob | {"hangupcause":21,"dialstatus":"","hangupsource":""} | | Bob is destroyed | AST\_CEL\_CHAN\_END | Bob | | | Alice is hung up | AST\_CEL\_HANGUP | Alice | {"hangupcause":17,"dialstatus":"BUSY","hangupsource":""} | | Alice is destroyed | AST\_CEL\_CHAN\_END | Alice | | @@ -362,7 +362,7 @@ For this scenario, assume that AST\_CEL\_ANSWER and AST\_CEL\_HANGUP are configu | David exits bridge Link2 | AST\_CEL\_BRIDGE\_EXIT | David | {"bridge\_id":"Link2"} | | David is hung up | AST\_CEL\_HANGUP | David | {"hangupcause":16,"dialstatus":"","hangupsource":""} | | David is destroyed | AST\_CEL\_CHANNEL\_END | David | | -| Alice and David execute an attended transfer  | AST\_CEL\_ATTENDEDTRANSFER | Alice | {"bridge1\_id":"Link1","channel2\_name":"David","bridge2\_id":"Link2"} | +| Alice and David execute an attended transfer | AST\_CEL\_ATTENDEDTRANSFER | Alice | {"bridge1\_id":"Link1","channel2\_name":"David","bridge2\_id":"Link2"} | | Alice exits bridge Link1 | AST\_CEL\_BRIDGE\_EXIT | Alice | {"bridge\_id":"Link1"} | | Alice is hung up | AST\_CEL\_HANGUP | Alice | {"hangupcause":16,"dialstatus":"","hangupsource":""} | | Alice is destroyed | AST\_CEL\_CHANNEL\_END | Alice | | diff --git a/docs/Configuration/WebRTC/Configuring-Asterisk-for-WebRTC-Clients.md b/docs/Configuration/WebRTC/Configuring-Asterisk-for-WebRTC-Clients.md index 14684f5325..946da7550d 100644 --- a/docs/Configuration/WebRTC/Configuring-Asterisk-for-WebRTC-Clients.md +++ b/docs/Configuration/WebRTC/Configuring-Asterisk-for-WebRTC-Clients.md @@ -205,7 +205,7 @@ An explanation of each of these settings parameters can be found on the [Asteris * Tell Asterisk to send media across the same transport that we receive it from. * Enable mux-ing of RTP and RTCP events onto the same socket. * Place received calls from this endpoint into an Asterisk [Dialplan](/Configuration/Dialplan) context called "default" -* And setup codecs by first disabling all and then selectively enabling Opus (presuming that you installed the Opus codec for Asterisk as mentioned at the beginning of this tutorial), then G.711 μ-law. +* And set up codecs by first disabling all and then selectively enabling Opus (presuming that you installed the Opus codec for Asterisk as mentioned at the beginning of this tutorial), then G.711 μ-law. ## Restart Asterisk diff --git a/docs/Configuration/WebRTC/WebRTC-tutorial-using-SIPML5.md b/docs/Configuration/WebRTC/WebRTC-tutorial-using-SIPML5.md index 49acd2191a..f63820ac53 100644 --- a/docs/Configuration/WebRTC/WebRTC-tutorial-using-SIPML5.md +++ b/docs/Configuration/WebRTC/WebRTC-tutorial-using-SIPML5.md @@ -8,7 +8,7 @@ Tutorial Overview This tutorial demonstrates basic WebRTC support and functionality within Asterisk. Asterisk will be configured to support a remote WebRTC client, the [sipml5](https://www.doubango.org/sipml5/) client, for the purposes of making calls to/from Asterisk within a web browser. You must be running a recent (as of September 2018) version of a Mozilla or Chromium based web browser. -Setup Asterisk +Set up Asterisk ============== Follow the instructions at [Configuring Asterisk for WebRTC Clients](/Configuration/WebRTC/Configuring-Asterisk-for-WebRTC-Clients) before proceeding, The rest of this tutorial assumes that your PBX is reachable at `pbx.example.com` and that the client is known as `webrtc_client`. diff --git a/docs/Contributing-to-the-Documentation.md b/docs/Contributing-to-the-Documentation.md index 7f7167f40f..c9e41604fa 100644 --- a/docs/Contributing-to-the-Documentation.md +++ b/docs/Contributing-to-the-Documentation.md @@ -382,7 +382,7 @@ Most of the pages that were converted from the old Confluence wiki use the `!!!` [//]: # (end-tip) ``` -That style is only supported for backwards compatibility and must not be used in new content. If you are editing a page with old style admonitions, you MUST convert them ALL to the new style. Mixing old and new styles will most probably cause the page to not be rendered correctly. +That style is only supported for backwards compatibility and must not be used in new content. If you are editing a page with old style admonitions, you MUST convert them ALL to the new style. Mixing old and new styles will most probably cause the page not to be rendered correctly. /// @@ -511,7 +511,7 @@ This can be useful to force wrap the text in table cells. Once you've made your updates, you'll want to test it locally to make sure everything renders properly. -### Setup the environment +### Set up the environment You've already cloned your fork of the documentation repo at this point but to set it up for building the documentation perform the following steps: @@ -637,4 +637,4 @@ Now run `make`: $ make BRANCHES=22 ``` -The main Makefile will automatically include the Makefile..inc file for any branch listed in BRANCHES. It doesn't make sense to build more than one branch in this situation but you could if you wanted to. You'll have to make sure there's a `Makefile..inc` file for each branch you want to build and that the paths in each file are adjusted to that branch's Asterisk files. +The main Makefile will automatically include the `Makefile..inc` file for any branch listed in BRANCHES. It doesn't make sense to build more than one branch in this situation but you could if you wanted to. You'll have to make sure there's a `Makefile..inc` file for each branch you want to build and that the paths in each file are adjusted to that branch's Asterisk files. diff --git a/docs/Deployment/Basic-PBX-Functionality/Registering-Phones-to-Asterisk.md b/docs/Deployment/Basic-PBX-Functionality/Registering-Phones-to-Asterisk.md index 1032b97ea8..d990cc9f4d 100644 --- a/docs/Deployment/Basic-PBX-Functionality/Registering-Phones-to-Asterisk.md +++ b/docs/Deployment/Basic-PBX-Functionality/Registering-Phones-to-Asterisk.md @@ -30,7 +30,7 @@ For chan_pjsip you can use **pjsip show endpoints**. !!! tip Debugging SIP Registrations - If you're having troubles getting a phone to register to Asterisk, make sure you watch the Asterisk CLI with the verbosity level set to at least three while you reboot the phone. You'll likely see error messages indicating what the problem is, like in this example: + If you're having trouble getting a phone to register to Asterisk, make sure you watch the Asterisk CLI with the verbosity level set to at least three while you reboot the phone. You'll likely see error messages indicating what the problem is, like in this example: [//]: # (end-tip) ``` diff --git a/docs/Deployment/PSTN-Connectivity/Signaling-System-Number-7.md b/docs/Deployment/PSTN-Connectivity/Signaling-System-Number-7.md index b44248d1d4..beed49b808 100644 --- a/docs/Deployment/PSTN-Connectivity/Signaling-System-Number-7.md +++ b/docs/Deployment/PSTN-Connectivity/Signaling-System-Number-7.md @@ -119,6 +119,6 @@ sigchan = 48 ; This would put two signalling channels in our linkset, one at ``` -This is how a basic linkset is setup. For more detailed chan_dahdi.conf SS7 config information as well as other options available for that file, see the default chan_dahdi.conf that comes with the samples in asterisk. If you would like, you can do a `make samples` in your asterisk-trunk directory and it will install a sample chan_dahdi.conf for you that contains +This is how a basic linkset is set up. For more detailed chan_dahdi.conf SS7 config information as well as other options available for that file, see the default chan_dahdi.conf that comes with the samples in asterisk. If you would like, you can do a `make samples` in your asterisk-trunk directory and it will install a sample chan_dahdi.conf for you that contains For more information, you can ask questions of the community on the asterisk-ss7 or asterisk-dev mailing lists. diff --git a/docs/Deployment/Secure-Calling/Secure-Calling-Tutorial/Installing-Blink-SIP-client.md b/docs/Deployment/Secure-Calling/Secure-Calling-Tutorial/Installing-Blink-SIP-client.md index 274f8fb7a3..97e2f7784c 100644 --- a/docs/Deployment/Secure-Calling/Secure-Calling-Tutorial/Installing-Blink-SIP-client.md +++ b/docs/Deployment/Secure-Calling/Secure-Calling-Tutorial/Installing-Blink-SIP-client.md @@ -15,7 +15,7 @@ Install some dependencies ------------------------- 1. \*Get latest Python 2.X -2. Setup repo from here: +2. Set up repo from here: 3. In your terminal, run the following commands ``` diff --git a/docs/Deployment/Troubleshooting/Troubleshooting-Asterisk-Module-Loading.md b/docs/Deployment/Troubleshooting/Troubleshooting-Asterisk-Module-Loading.md index 5f73f76f31..56a1239364 100644 --- a/docs/Deployment/Troubleshooting/Troubleshooting-Asterisk-Module-Loading.md +++ b/docs/Deployment/Troubleshooting/Troubleshooting-Asterisk-Module-Loading.md @@ -74,7 +74,7 @@ noload => chan_sip.so ``` -That would tell Asterisk to not load chan_sip.so. +That would tell Asterisk not to load chan_sip.so. If you are not using **autoload**, then be sure you have a **load** line for the module you desire to load. diff --git a/docs/Deployment/Troubleshooting/Unable-to-connect-to-remote-Asterisk.md b/docs/Deployment/Troubleshooting/Unable-to-connect-to-remote-Asterisk.md index ad7e4c6e84..db2a31f70c 100644 --- a/docs/Deployment/Troubleshooting/Unable-to-connect-to-remote-Asterisk.md +++ b/docs/Deployment/Troubleshooting/Unable-to-connect-to-remote-Asterisk.md @@ -72,7 +72,7 @@ You need to find out what error is causing Asterisk to halt and resolve it. --- This will start Asterisk in console mode with level 5 verbosity. That should give you plenty to look at. -* Another way is to setup Asterisk [Logging](/Operation/Logging) to log what you want to see to a file. You'll need to read up on Asterisk's [Logging Configuration](/Configuration/Core-Configuration/Logging-Configuration) +* Another way is to set up Asterisk [Logging](/Operation/Logging) to log what you want to see to a file. You'll need to read up on Asterisk's [Logging Configuration](/Configuration/Core-Configuration/Logging-Configuration) * Asterisk could halt for a variety of reasons. The last messages you see before Asterisk halts will give you a clue. Then you can Google from there or ask the user community. ### Cause 4: SELinux enabled and not properly configured for Asterisk. SELinux not allowing asterisk.ctl to be created. diff --git a/docs/Development/Policies-and-Procedures/Coding-Guidelines.md b/docs/Development/Policies-and-Procedures/Coding-Guidelines.md index d5fa3bf701..c5556717f1 100644 --- a/docs/Development/Policies-and-Procedures/Coding-Guidelines.md +++ b/docs/Development/Policies-and-Procedures/Coding-Guidelines.md @@ -106,7 +106,7 @@ If you need to create a detached thread, use the `ast_pthread_create_detached()` ### Code formatting Roughly, Asterisk code formatting guidelines are generally equivalent to the following: -  + /// warning Running the indent command on an existing module may result in drastic alterations to it or indentation that is actually incorrect. It is recommended that if you are making changes to existing code that you manually indent. If you would like to fix the indentation of an existing module this should be done as a separate review. /// diff --git a/docs/Development/Policies-and-Procedures/Module-Deprecation.md b/docs/Development/Policies-and-Procedures/Module-Deprecation.md index 549a00e712..42b3e1e0c0 100644 --- a/docs/Development/Policies-and-Procedures/Module-Deprecation.md +++ b/docs/Development/Policies-and-Procedures/Module-Deprecation.md @@ -13,12 +13,12 @@ On This Page Policy ====== -Asterisk follows a 2 year module deprecation process. A module is initially marked as deprecated and set to not be built by default in a standard release which is carried over to the next long term supported release. This provides a period of 2 releases and thus 2 years where the module is marked as deprecated. In the next standard release the module is then removed from the source code tree entirely which is carried over to the next long term supported release. As an example (note that this has not occurred), +Asterisk follows a 2 year module deprecation process. A module is initially marked as deprecated and set not to be built by default in a standard release which is carried over to the next long term supported release. This provides a period of 2 releases and thus 2 years where the module is marked as deprecated. In the next standard release the module is then removed from the source code tree entirely which is carried over to the next long term supported release. As an example (note that this has not occurred), -1. The app_alarmreceiver is marked as deprecated in master and set to not build by default +1. The app_alarmreceiver is marked as deprecated in master and set not to build by default 2. Previous version branches (such as 16 and 18) are updated with the version in which app_alarmreceiver is to be deprecated (19) and the version it is to be removed (21) to display it to the user -3. The Asterisk 19 (standard release) branch is created from master with app_alarmreceiver marked as deprecated and set to not build by default -4. The Asterisk 20 (long term supported release) branch is created from master with app_alarmreceiver marked as deprecated and set to not build by default +3. The Asterisk 19 (standard release) branch is created from master with app_alarmreceiver marked as deprecated and set not to build by default +4. The Asterisk 20 (long term supported release) branch is created from master with app_alarmreceiver marked as deprecated and set not to build by default 5. The app_alarmreceiver module is removed from master 6. The Asterisk 21 (standard release) branch is created from master with app_alarmreceiver removed 7. The Asterisk 22 (long term supported release) branch is created from master with app_alarmreceiver removed diff --git a/docs/Development/Policies-and-Procedures/New-Features-and-Improvements.md b/docs/Development/Policies-and-Procedures/New-Features-and-Improvements.md index e416b6e846..9500d8879d 100644 --- a/docs/Development/Policies-and-Procedures/New-Features-and-Improvements.md +++ b/docs/Development/Policies-and-Procedures/New-Features-and-Improvements.md @@ -26,7 +26,7 @@ Decision Not To Accept A New Feature Or Improvement While we understand that contributors prefer that new features and improvements they create become part of Asterisk, it is not always possible for the Asterisk project to accept them. This may be because the feature or improvement is extremely specialized, or because it would see little to no use by others. Having a specialized or limited use feature or improvement in Asterisk makes the project responsible for all aspects of the feature or improvement and will consume time that would be otherwise used on non-specialized or widely used capabilities. Therefore, the Asterisk project may choose not to accept a new feature or improvement. Such decisions are not taken lightly and are done in consultation with the asterisk-dev mailing list. !!! note - If a new feature or improvement patch is submitted for review on Gerrit without prior discussion, and a reviewer voices an opinion to not allow the new feature or improvement, or desires more discussion about it then the review may be suspended (given a -2), and the submitter will be required to create a new post to initiate further discussion on the asterisk-dev mailing list about the change, and why it should be allowed in. + If a new feature or improvement patch is submitted for review on Gerrit without prior discussion, and a reviewer voices an opinion not to allow the new feature or improvement, or desires more discussion about it then the review may be suspended (given a -2), and the submitter will be required to create a new post to initiate further discussion on the asterisk-dev mailing list about the change, and why it should be allowed in. [//]: # (end-note) diff --git a/docs/Development/Policies-and-Procedures/Software-Configuration-Management-Policies.md b/docs/Development/Policies-and-Procedures/Software-Configuration-Management-Policies.md index e98f8fb915..8aeb1c52f9 100644 --- a/docs/Development/Policies-and-Procedures/Software-Configuration-Management-Policies.md +++ b/docs/Development/Policies-and-Procedures/Software-Configuration-Management-Policies.md @@ -84,14 +84,14 @@ New features should follow the same procedure as bug fixes however they are, sub + Configuration and database schemas can be added to or updated, but users should not be required to update their configuration or databases. * Any new features or improvements **must** be included in the first release candidate of a new version. First release candidate announcements must be made to the `asterisk-users` mailing lists, with at least a week of testing time allowed. If a new feature or improvement is deemed to cause an inappropriate burden on end-users, it **must** be removed from the release. -Generally, new features or improvements should always be done as new modules where possible, and those modules should be disabled if included in a release branch. If changes are necessary to the Asterisk core, all care possible should be given to not impact existing modules. +Generally, new features or improvements should always be done as new modules where possible, and those modules should be disabled if included in a release branch. If changes are necessary to the Asterisk core, all care possible should be given not to impact existing modules. Note that if a new feature radically changes the architecture of Asterisk and the next planned major version branch is an LTS branch, you may be asked to defer the change until the next Standard branch is being developed. Major Version Stability ======================= -Once a major version branch has been made, all effort shall be made by Asterisk developers to not introduce breaking changes into that major version. +Once a major version branch has been made, all effort shall be made by Asterisk developers not to introduce breaking changes into that major version. What is a breaking change? diff --git a/docs/Development/Roadmap/Asterisk-10-Projects/Codecs-and-Audio-Formats/index.md b/docs/Development/Roadmap/Asterisk-10-Projects/Codecs-and-Audio-Formats/index.md index d58fd8e58b..21ca402b47 100644 --- a/docs/Development/Roadmap/Asterisk-10-Projects/Codecs-and-Audio-Formats/index.md +++ b/docs/Development/Roadmap/Asterisk-10-Projects/Codecs-and-Audio-Formats/index.md @@ -107,7 +107,7 @@ In this example, three different CELT codecs are created: one for 32kHz mode, on These codecs cannot be dynamically changed while Asterisk is running. In order to make changes, an Asterisk restart is required. -To make sure a codec or format is setup correctly, you can execute: +To make sure a codec or format is set up correctly, you can execute: core show codecs @@ -198,7 +198,7 @@ In this example, four different SILK codecs are created: one each for 8 (silk8), These codecs cannot be dynamically changed while Asterisk is running. In order to make changes, an Asterisk restart is required. -To make sure a codec or format is setup correctly, you can execute: +To make sure a codec or format is set up correctly, you can execute: core show codecs diff --git a/docs/Development/Roadmap/Asterisk-10-Projects/Media-Architecture-Proposal.md b/docs/Development/Roadmap/Asterisk-10-Projects/Media-Architecture-Proposal.md index ae6f2aa9a2..1ee04dc943 100644 --- a/docs/Development/Roadmap/Asterisk-10-Projects/Media-Architecture-Proposal.md +++ b/docs/Development/Roadmap/Asterisk-10-Projects/Media-Architecture-Proposal.md @@ -1087,7 +1087,7 @@ During ast_channel_make_compatible(), if it is determined that translation is re # Implementation Phases -With a project of this size, it is important to break down the implementation into manageable phases. Each phase of development contains a set of steps which act as milestones. These steps must be small enough to be attainable within a week to two week period but complete enough to not break any Asterisk functionality once they are introduced. Once a step is complete, it should be reviewed and committed into trunk. This allows progress to be made in a maintainable way. +With a project of this size, it is important to break down the implementation into manageable phases. Each phase of development contains a set of steps which act as milestones. These steps must be small enough to be attainable within a week to two week period but complete enough not to break any Asterisk functionality once they are introduced. Once a step is complete, it should be reviewed and committed into trunk. This allows progress to be made in a maintainable way. ## Phase 1: Re-architect how media is represented and how translation paths are built diff --git a/docs/Development/Roadmap/Asterisk-12-Projects/Asterisk-12-Bridging-Project/index.md b/docs/Development/Roadmap/Asterisk-12-Projects/Asterisk-12-Bridging-Project/index.md index 562e991bc0..007b3f8520 100644 --- a/docs/Development/Roadmap/Asterisk-12-Projects/Asterisk-12-Bridging-Project/index.md +++ b/docs/Development/Roadmap/Asterisk-12-Projects/Asterisk-12-Bridging-Project/index.md @@ -36,7 +36,7 @@ A comment from ast_do_masquerade ``` -The way the operation works is to take two channels and 'swap' portions of them. In the diagram below, assume that Thread A has a channel that Thread B wants to take over. Thread B creates a new channel ("Original") and starts a Masquerade operation on the channel owned by Thread A ("Clone"). Both channels are locked, and the state of the Clone channel is moved into the Original channel, while the Clone channel obtains the Original channel's state. In order to denote that the channel is about to die, a special ZOMBIE flag is put on the channel and the name renamed to Clone. The lock is released, and the Original channel - which now has the state associated with Clone channel - executes in Thread B, while the Clone channel (which is now quite dead) see's that its dead and goes off to silently contemplate its demise in an `h` extension. +The way the operation works is to take two channels and 'swap' portions of them. In the diagram below, assume that Thread A has a channel that Thread B wants to take over. Thread B creates a new channel ("Original") and starts a Masquerade operation on the channel owned by Thread A ("Clone"). Both channels are locked, and the state of the Clone channel is moved into the Original channel, while the Clone channel obtains the Original channel's state. In order to denote that the channel is about to die, a special ZOMBIE flag is put on the channel and the name renamed to `Clone`. The lock is released, and the Original channel - which now has the state associated with Clone channel - executes in Thread B, while the Clone channel (which is now quite dead) sees that it's dead and goes off to contemplate its demise silently in an `h` extension. Asterisk_12_MasqueradesL Except, of course, that this is a dramatic simplification. It's never quite that easy. @@ -341,11 +341,11 @@ Moves chan into the parking bridge and replaces the swap channel already in the #### Add new CHANNEL() option: -CHANNEL(after_bridge_goto)= +`CHANNEL(after_bridge_goto)=` #### BridgeWait() -Potential new dialplan appliction that puts the channel into a holding bridge that the Bridge application or the Bridge AMI action can move to the real bridge. This will avoid the need for a masquerade when the Wait application is used. The Bridge applicaiton and Bridge AMI action will need to be modified to not use masquerades unconditionally if these channels can be moved from the current bridge they are in. +Potential new dialplan application that puts the channel into a holding bridge that the Bridge application or the Bridge AMI action can move to the real bridge. This will avoid the need for a masquerade when the Wait application is used. The Bridge application and Bridge AMI action will need to be modified not to use masquerades unconditionally if these channels can be moved from the current bridge they are in. #### More Stuff @@ -359,7 +359,7 @@ It would be nice to implement DTMF attended transfer to be able to toggle back a Bridge channel hooks can move the bridge channel between bridges. This would be needed to implement the toggle between A and C bridges feature. -A way to implement the toggle between A and C parties is to have an atxfer bridge subclass. Setup the links this way: +A way to implement the toggle between A and C parties is to have an atxfer bridge subclass. Set up the links this way: ``` @@ -785,7 +785,7 @@ Project Planning High Level Bridging construction tasks: --------------------------------------- -* **DONE** Change ast_bridge_call callers to not expect getting peer back. Part of this is to add an optional goto dialplan location datastore to set where the peer should go when it exits the bridge. The location datastore is removed if a channel exits with AST_SOFTHANGUP_ASYNCGOTO set or the channel is masqueraded. Part of this is to implement the self managing bridge functionality. +* **DONE** Change ast_bridge_call callers not to expect getting peer back. Part of this is to add an optional goto dialplan location datastore to set where the peer should go when it exits the bridge. The location datastore is removed if a channel exits with AST_SOFTHANGUP_ASYNCGOTO set or the channel is masqueraded. Part of this is to implement the self managing bridge functionality. * **DONE** Make all bridge technologies have a bridging thread to handle bridge restructuring tasks like smart bridge and bridge merges. When the bridge thread is not being used to restructure the diff --git a/docs/Development/Roadmap/Asterisk-13-Projects/Resource-List-Subscriptions/PJSIP-Large-Messages.md b/docs/Development/Roadmap/Asterisk-13-Projects/Resource-List-Subscriptions/PJSIP-Large-Messages.md index 28e5235c09..2f852ab9cd 100644 --- a/docs/Development/Roadmap/Asterisk-13-Projects/Resource-List-Subscriptions/PJSIP-Large-Messages.md +++ b/docs/Development/Roadmap/Asterisk-13-Projects/Resource-List-Subscriptions/PJSIP-Large-Messages.md @@ -486,7 +486,7 @@ This does a better job of overcoming the inflexibility of the second proposed so ### In Asterisk -##### Change RLS full state notifications to not include resource instances +##### Change RLS full state notifications not to include resource instances While RFC 4662 states that full state notifications must be sent when sending a NOTIFY in response to a SUBSCRIBE, it is somewhat ambiguous about whether a full state notification actually has to have instance data for each of the resources. Evidence on the sip-implementors mailing list suggests that it has been advised of people to send only the names and URIs of resources when sending a full state notification and then sending the actual instances of the resources in subsequent partial state notifications. diff --git a/docs/Development/Roadmap/Asterisk-14-Projects/ARI-Feature-Wish-list.md b/docs/Development/Roadmap/Asterisk-14-Projects/ARI-Feature-Wish-list.md index c8d9e31c1b..d00a197b21 100644 --- a/docs/Development/Roadmap/Asterisk-14-Projects/ARI-Feature-Wish-list.md +++ b/docs/Development/Roadmap/Asterisk-14-Projects/ARI-Feature-Wish-list.md @@ -5,7 +5,7 @@ pageid: 32375021 ## Overview -The ARI Feature Wish-List has been setup to help collect ideas from the wider ARI community. If you're using ARI to build applications or developing an ARI framework, we're interested in your thoughts, suggestions and feedback. You can contribute by either posting a comment or by joining the conversation in the #asterisk-dev or #asterisk-ari channels over on freenode. Remember, unless you want to write the feature yourself, there's no guarantee it will be done. +The ARI Feature Wish-List has been set up to help collect ideas from the wider ARI community. If you're using ARI to build applications or developing an ARI framework, we're interested in your thoughts, suggestions and feedback. You can contribute by either posting a comment or by joining the conversation in the #asterisk-dev or #asterisk-ari channels over on freenode. Remember, unless you want to write the feature yourself, there's no guarantee it will be done. ## Non-JIRA Feature Requests @@ -29,7 +29,7 @@ Don't see your Wish-List request below? Ask in #asterisk-ari on freenode. | Stasis dialplan result variable | Set a channel variable on a channel if it can't get placed into a Stasis dialplan application. | 16/3/2015 | | Done | | Increase HTTP max content length | The HTTP max content length is currently 4k. That limits some of the requests that can be made. | 16/3/2015 | | Done | | Add/Remove Sounds | Allow ARI to be used to push new sounds to asterisk storage over HTTP and also deleted | 16/3/2015 | | | -| ARI Debug | Allow ARI debug information at console, like sip set debug, we could have: ari set debug on/off. Could show details about messages passed between application and asterisk. Could be filtered by Stasis app too, e.g. "ari set debug on" | 05/05/2015 | | Done | +| ARI Debug | Allow ARI debug information at console, like sip set debug, we could have: ari set debug on/off. Could show details about messages passed between application and asterisk. Could be filtered by Stasis app too, e.g. `ari set debug on` | 05/05/2015 | | Done | | ari show applications | Ability to list applications from the console. Show details like IP of application websocket endpoint, duration, missed msg's(?) | 01/08/2016 | | Done | | Bridged DTMF Pass-through | Expose ability to set pass-through behavior of DTMF on bridges at bridge creation or when a channel is added to a bridge | 05/08/2016 | | | | Connection without user | Allow ARI requests to be initiated without requiring authentication or a user | 15/08/2016 | | | diff --git a/docs/Development/Roadmap/Asterisk-14-Projects/Git-Migration.md b/docs/Development/Roadmap/Asterisk-14-Projects/Git-Migration.md index d738d34b84..12a9efa4a5 100644 --- a/docs/Development/Roadmap/Asterisk-14-Projects/Git-Migration.md +++ b/docs/Development/Roadmap/Asterisk-14-Projects/Git-Migration.md @@ -52,10 +52,10 @@ Below is a comparison of four platforms, subjected to a variety of criteria: | **Project Management** | Issues, Wiki, Pull Requests, Code Review are all built in. | Issues, Wiki, Pull Requests, Code Review are all built in. | Issues, Wiki, Pull Requests, Code Review are all built in. | None. Although we have alternate solutions for Issues, Wikis, and Code Review, a solution for Pull Requests would be nice. Contributors could work on pull requests using their own Github account and submit their work via patches to Review Board. | Does not encompass Issues. The overall workflow includes code review/project managements through Gerrit and CI through Jenkins/Zuul. This would replace Review Board and Bamboo. | | **Protected Branches** | Permissions are only supported at the repository level. A client hook could be installed to prevent pushing certain branches but this could not be enforced on the server. | Protected branches are supported, whether or not they have been created yet, but are not enforced when forking or creating a repository that acts as another remote. Custom Stash hooks could be implementing to stop certain branches from been pushed but must be installed manually per repository. | Protected branches are supported but must first be created with at least one file in the given branch. Forking or creating a repository that acts as another remote removes all permissions related to protected branches. The enterprise edition supports git hooks but they appear to be limited at this time although their project page mentions that they are prepared to implement new hooks as requested. These hooks would have to be enabled on a per repository basis. | Protected branches are supported, whether or not they have been created yet. Since permissions are defined using regular expressions, repositories do not have to exist before permissions can be applied. | Gerrit supports permissions on a per branch basis. | | **Rewriting History** | No protection against rewriting history. A client side hook could be installed to prevent this but could not be enforced on the server. | Permissions allow protecting against rewriting history. | Permissions allow protecting against rewriting history. | Permissions allow protecting against rewriting history. | Permissions allow protecting against rewriting history, but can be overridden. | -| **Arbitrary Repository Creation (Team Repositories)** | Users can create arbitrary repositories under their own Github account for the purposes of creating pull requests. | A team repository project can be created to allow users to create arbitrary repositories. | Users can create arbitrary repositories under their name, in a similar fashion to Github. | A regular expression permission can be setup to create wildcard repositories to support team repositories. | User would need ability to create projects in Gerrit. | +| **Arbitrary Repository Creation (Team Repositories)** | Users can create arbitrary repositories under their own Github account for the purposes of creating pull requests. | A team repository project can be created to allow users to create arbitrary repositories. | Users can create arbitrary repositories under their name, in a similar fashion to Github. | A regular expression permission can be set up to create wildcard repositories to support team repositories. | User would need ability to create projects in Gerrit. | | **Git Hooks** | Installing git hooks is not supported at this time. | Custom Stash hooks can be installed as plugins on a per repository basis. These hooks differ from git hooks in that they must be written using Atlassian's API for hooks using Java. | Only the enterprise edition supports this. | Git hooks are supported plus additional hooks provided by Gitolite to support calling hooks before git is invoked or after a repository is created. | Yes | | **Web Hooks** | Web hooks are supported and could be used to sync commits with other products/platforms. | Web hooks are not supported but custom Stash hooks could be written to implement syncing with other products/platforms. | Web hooks are supported and could be used to sync commits with other products/platforms. | Web hooks are not supported. Git hooks would have to be created to support syncing with other products/platforms. | Gerrit has an event stream. | -| **Performance** | Github's performance has been showed to be more than adequate. Minimal downtime has occurred in the past. | Year old issue mentions timeouts when cloning large repositories which appears to have been fixed. No other information on performance issues could be found. | Recent issues mention timeouts when cloning large repositories. Another issue mentions problems when rendering graphs for repositories with large number of commits. Issues appear to not have been fixed yet. | Since Gitolite is thin wrapper around git, performance is very close to that of git. I could not find any information on performance issues. | Yes | +| **Performance** | Github's performance has been showed to be more than adequate. Minimal downtime has occurred in the past. | Year old issue mentions timeouts when cloning large repositories which appears to have been fixed. No other information on performance issues could be found. | Recent issues mention timeouts when cloning large repositories. Another issue mentions problems when rendering graphs for repositories with large number of commits. Issues appear not to have been fixed yet. | Since Gitolite is thin wrapper around git, performance is very close to that of git. I could not find any information on performance issues. | Yes | | **Process Recommendation** | A public repository for contributors to post pull requests and clone/pull from along with a private repository for pushing commits to. The public repository would in effect be a mirror of selected branches from the private one. This mirror may or may not be done automatically. A limited number of commiters to control what commits/branches are pushed to the public/private repository. | A public and a private instance with custom Stash hooks to prevent certain branches from been pushed, which would have to be enabled on a per repository basis. The public repository would in effect be a mirror of the private repository where pull requests can be created and contributors can clone/pull from. As with Github, a limited number of commiters to control what commits/branches are pushed to the public/private repositories. Rewriting history should only be allowed for team repositories and for admins. | A public and a private instance with custom enterprise edition hooks to prevent certain branches from been pushed, which would have to be enabled on a per repository basis. The public repository would in effect be a mirror of the private repository where pull requests can be created and contributors can clone/pull from. As with Github and Stash, a limited number of commiters to control what commits/branches are pushed to the public/private repositories. Rewriting history should only be allowed for team repositories and for admins. | A public and a private instance using permissions to protect certain branches and to allow team repositories. Rewriting history should only be allowed for team repositories and for admins. As with Github, Stash, and Gitlab, a limited number of commiters to control what commits/branches are pushed to the public/private repositories. | Use a model similar to open stack model. Anyone can contribute. Once approved, developers with higher permissions can push to a branch. | Notes diff --git a/docs/Development/Roadmap/Asterisk-14-Projects/Module-Loader-Ideas.md b/docs/Development/Roadmap/Asterisk-14-Projects/Module-Loader-Ideas.md index 18f36bc1ae..88a8e0f308 100644 --- a/docs/Development/Roadmap/Asterisk-14-Projects/Module-Loader-Ideas.md +++ b/docs/Development/Roadmap/Asterisk-14-Projects/Module-Loader-Ideas.md @@ -190,7 +190,7 @@ Embedding needs to be set for all modules at once, or per module. menuselect do ### Circular dependencies -Circular dependencies would have to be broken by use of "canuse" in at least one link of the loop - on a module that implements an optional API. In theory we could add a "willuse" - a tag that would cause another module to be loaded immediately after the module that lists it as "willuse". This is a difficult thing to deal with, the better option would be to fix the modules to not have circular dependencies. +Circular dependencies would have to be broken by use of "canuse" in at least one link of the loop - on a module that implements an optional API. In theory we could add a "willuse" - a tag that would cause another module to be loaded immediately after the module that lists it as "willuse". This is a difficult thing to deal with, the better option would be to fix the modules not to have circular dependencies. To my knowledge there are not currently any circular dependencies in MODULEINFO blocks. The module loader will need to protect itself against that (infinite dependency load recursion). My immediate reaction is that circular dependencies need to prevent those modules from loading. This may also be good reason for a 'make check' target. This would not run the testsuite or even unit tests, but would be the right place to do things like validate XMLDOC against schema, ensure module manifests have no errors, etc. diff --git a/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/Notes-on-RTP-standards.md b/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/Notes-on-RTP-standards.md index 88ab76feb6..7b5ef72d06 100644 --- a/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/Notes-on-RTP-standards.md +++ b/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/Notes-on-RTP-standards.md @@ -157,7 +157,7 @@ ICE has a flavor called "ICE lite" that may be used by peers, which means that w Trickle-ICE (draft-ietf-mmusic-trickle-ice) ------------------------------------------- -This modifies the behavior of ICE by essentially making it asynchronous. Rather than waiting for all local candidates to be learned before sending an offer or answer, trickle ICE allows for candidates to be sent as they are learned instead. It also allows for connectivity checks to be performed as soon as candidate pairs can be created. It makes modifications to language from RFC 5245 in order to not claim check lists have failed prematurely. Interestingly, this draft mentions the recommendation of using RFC 3388 (which is actually obsoleted by RFC 5888) MIDs in order to associate new ICE candidates with an existing media offer. +This modifies the behavior of ICE by essentially making it asynchronous. Rather than waiting for all local candidates to be learned before sending an offer or answer, trickle ICE allows for candidates to be sent as they are learned instead. It also allows for connectivity checks to be performed as soon as candidate pairs can be created. It makes modifications to language from RFC 5245 in order not to claim check lists have failed prematurely. Interestingly, this draft mentions the recommendation of using RFC 3388 (which is actually obsoleted by RFC 5888) MIDs in order to associate new ICE candidates with an existing media offer. The method of indicating new candidates the remote entity is not mentioned in this draft. For SIP, draft-ivov-mmusic-trickle-ice-sip has been defined. It specifies using the INFO method with a newly-defined INFO package in order to trickle in new candidates. This means that in addition to RTP stack changes, some SIP-level changes would need to be made in order to understand the new INFO package, as well as have the ability to signal to the RTP layer that new candidates have been trickled in. It also means that there has to be a common interface (independent of which Asterisk SIP implementation is in use?) that allows for the RTP layer to send a SIP INFO when new local candidates are harvested. diff --git a/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/RTP-task-list.md b/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/RTP-task-list.md index 03e4634966..7a8ec73fcd 100644 --- a/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/RTP-task-list.md +++ b/docs/Development/Roadmap/Asterisk-14-Projects/RTP-engine-replacement/RTP-task-list.md @@ -289,7 +289,7 @@ These RTP features go beyond the humble Strict RTP ---------- -Strict RTP is an Asterisk security feature that prevents injection of media from unknown sources. RFC 3550 provides an algorithm in Appendix A.1 that allows for an RTP implementation to not accept packets from a new SSRC until after receiving a certain minimum number of RTP packets from that SSRC. Strict RTP is similar, except that +Strict RTP is an Asterisk security feature that prevents injection of media from unknown sources. RFC 3550 provides an algorithm in Appendix A.1 that allows for an RTP implementation not to accept packets from a new SSRC until after receiving a certain minimum number of RTP packets from that SSRC. Strict RTP is similar, except that * Rather than applying the algorithm to new SSRCs, we apply the algorithm to source IP addresses and ports on arriving packets. * We have to recognize periods where our strictness needs to be opened back up and reset the learning period. diff --git a/docs/Development/Roadmap/Asterisk-15-Projects/Simulcast-and-SVC.md b/docs/Development/Roadmap/Asterisk-15-Projects/Simulcast-and-SVC.md index 03303ec98d..0a14e519bb 100644 --- a/docs/Development/Roadmap/Asterisk-15-Projects/Simulcast-and-SVC.md +++ b/docs/Development/Roadmap/Asterisk-15-Projects/Simulcast-and-SVC.md @@ -15,7 +15,7 @@ Support exists for simulcast within both Google Chrome and Firefox. They differ ### Chrome -The [Chrome implementation](http://www.rtcbits.com/2014/09/using-native-webrtc-simulcast-support.html) stems from the days of Google Hangouts. It does not implement the RFC and is very simple. Each alternative stream is defined as another SSRC within the SDP and simulcast is enabled by creating a SIM ssrc-group. The quality is fixed within Chrome itself to not exceed specific maximums. The RTCP exchange determines what substreams Chrome will send. +The [Chrome implementation](http://www.rtcbits.com/2014/09/using-native-webrtc-simulcast-support.html) stems from the days of Google Hangouts. It does not implement the RFC and is very simple. Each alternative stream is defined as another SSRC within the SDP and simulcast is enabled by creating a SIM ssrc-group. The quality is fixed within Chrome itself not to exceed specific maximums. The RTCP exchange determines what substreams Chrome will send. ### Firefox diff --git a/docs/Development/Roadmap/Asterisk-15-Projects/Stream-Support.md b/docs/Development/Roadmap/Asterisk-15-Projects/Stream-Support.md index 89365b35ea..b1b3dbfb48 100644 --- a/docs/Development/Roadmap/Asterisk-15-Projects/Stream-Support.md +++ b/docs/Development/Roadmap/Asterisk-15-Projects/Stream-Support.md @@ -8,7 +8,7 @@ Streams! ALL THE STREAMS! Let's start with talking about what streams are. Streams at their core are a flow of media. They can be unidirectional or bidirectional and are comprised of media formats. The media formats also contain a type. To simplify things streams only carry a single type of media. Streams can also carry an identifier in the form of a name. -Asterisk currently has no explicit interface for streams and simply has a single pipe that frames are written to and read from. The negotiated formats are scoped to the entire channel as a result. Interfaces that need to manipulate media have injected themselves into this single pipe and have to take special care to not manipulate frames they do not need to. This pipe also carries control frames and other signaling related operations. This means that there is a single very loose stream for each type of media. +Asterisk currently has no explicit interface for streams and simply has a single pipe that frames are written to and read from. The negotiated formats are scoped to the entire channel as a result. Interfaces that need to manipulate media have injected themselves into this single pipe and have to take special care not to manipulate frames they do not need to. This pipe also carries control frames and other signaling related operations. This means that there is a single very loose stream for each type of media. So what do we need to be able to do for streams? ================================================ diff --git a/docs/Development/Roadmap/Asterisk-18-Projects/Advanced-Codec-Negotiation-ACN.md b/docs/Development/Roadmap/Asterisk-18-Projects/Advanced-Codec-Negotiation-ACN.md index f04e51d0ee..a774ff8574 100644 --- a/docs/Development/Roadmap/Asterisk-18-Projects/Advanced-Codec-Negotiation-ACN.md +++ b/docs/Development/Roadmap/Asterisk-18-Projects/Advanced-Codec-Negotiation-ACN.md @@ -114,7 +114,7 @@ Allowed values: yes - Allow transcoding based on default "call" setup (default). -no - Never allow transcoding. Setting this could cause some calls to not get setup. +no - Never allow transcoding. Setting this could cause some calls not to get set up. always - Always transcode even if both sides negotiate the same codec(s). diff --git a/docs/Development/Roadmap/AstriDevCon-2011.md b/docs/Development/Roadmap/AstriDevCon-2011.md index fa66cc42f1..cc5cc2839a 100644 --- a/docs/Development/Roadmap/AstriDevCon-2011.md +++ b/docs/Development/Roadmap/AstriDevCon-2011.md @@ -248,7 +248,7 @@ P1 is the highest priority. - atomic commits across modules * This is not trivial. Modules should refuse to load new configuration unless all other modules have successfully loaded theirs. * Allow Originate() dialplan application and CLI originate command to pass variables to the channel -* Update modules that require app_macro to not require it; prefer app_stack (GoSub) +* Update modules that require app_macro not to require it; prefer app_stack (GoSub) ### (P0) diff --git a/docs/Development/Roadmap/AstriDevCon-2012.md b/docs/Development/Roadmap/AstriDevCon-2012.md index 28313c95e5..f6ac160ff7 100644 --- a/docs/Development/Roadmap/AstriDevCon-2012.md +++ b/docs/Development/Roadmap/AstriDevCon-2012.md @@ -130,7 +130,7 @@ Please remember that these notes merely represent the items that were discussed, + Announce on mailing list when a project is kicked off - provide links to wiki for more detail + Page should include requirements, high level design, links to JIRA issues for tasking, links to code reviews, outstanding tasks, etc. * Mailing list policies - + We currently require all mailing list discussions to be conducted only through the mailman server, i.e., you can't CC the mailing list. This can make it difficult if a particular mailing list is not one that you interact with on a constant basis. A proposal was made to not require mailing list discussions to be conducted only through mailman server. + + We currently require all mailing list discussions to be conducted only through the mailman server, i.e., you can't CC the mailing list. This can make it difficult if a particular mailing list is not one that you interact with on a constant basis. A proposal was made not to require mailing list discussions to be conducted only through mailman server. + Counter-argument: the configuration would most likely need need tweaks for duplicate messages, and allowing conversations to CC a mailing list might mean that conversations fall off of the list easier (or never get put on it in the first place) + **We didn't seem to come to a conclusion on this issue. If anyone feels like this needs more discussion, please start a policy discussion on the asterisk-dev list.** diff --git a/docs/Development/Roadmap/AstriDevCon-2015.md b/docs/Development/Roadmap/AstriDevCon-2015.md index 642fdd9123..e8af731764 100644 --- a/docs/Development/Roadmap/AstriDevCon-2015.md +++ b/docs/Development/Roadmap/AstriDevCon-2015.md @@ -212,7 +212,7 @@ Open Discussion - I'd like to offer a Docker image that you can run an ARI hello world in - Goal: Have an Asterisk image that people can load up and use - Daniel: How about VirtualBox? - - Could be anything, so long as it is easy to setup, deploy, and throw away + - Could be anything, so long as it is easy to set up, deploy, and throw away * Video + Ben/Dan: Don't reinvent the wheel + Farm out to FreeSWITCH or Jitsi videobridge diff --git a/docs/Development/Roadmap/AstriDevCon-2016.md b/docs/Development/Roadmap/AstriDevCon-2016.md index 58cb09495b..ab4b19edaf 100644 --- a/docs/Development/Roadmap/AstriDevCon-2016.md +++ b/docs/Development/Roadmap/AstriDevCon-2016.md @@ -301,7 +301,7 @@ Should we deprecate chan_sip? * Benefit to security to deprecate it sooner rather than later. As chan_sip ages without attention, it will become a security risk. * Large portion of community still reliant on chan_sip.. a lot of pain to move too soon. -* A lot of reasons to not deprecate anytime soon, and a lot of reasons to deprecate it sooner rather than later. +* A lot of reasons not to deprecate anytime soon, and a lot of reasons to deprecate it sooner rather than later. * We are on the path..chan_sip was already moved to extended support in 12. * Matt F doesn't want to nail down a specific time yet. diff --git a/docs/Development/Roadmap/AstriDevCon-2017.md b/docs/Development/Roadmap/AstriDevCon-2017.md index 628d8bfef1..97dc64b159 100644 --- a/docs/Development/Roadmap/AstriDevCon-2017.md +++ b/docs/Development/Roadmap/AstriDevCon-2017.md @@ -817,7 +817,7 @@ What 3 features are missing? CCSS, AOC and outbound Subscriptions. The only on What about stability? The FreePBX community has a large thread with users indicating issues with PJSIP that they don’t experience with chan_sip, but no one is filing bugs or presenting actual issues - it appears to be primarily anecdotal. -Is it already defacto deprecated since it’s in extended support and there is no community maintainer? And, are we being setup for something bad by not making it more clear. +Is it already defacto deprecated since it’s in extended support and there is no community maintainer? And, are we being set up for something bad by not making it more clear. What about configuration? The converter isn’t necessarily feature complete; but is written in Python (hint, non-C developers) There’s built-in help in Asterisk’s CLI (config show help [res_pjsip_endpoint.so](http://res_pjsip_endpoint.so), for example). Is it worthwhile to make PJSIP read sip.conf? (There are problems here as a friend and a peer are different and if you move that to PJSIP under the hood you can end up with weird configuration or vulnerability issues) diff --git a/docs/Development/Roadmap/AstriDevCon-2019/Agenda-2019.md b/docs/Development/Roadmap/AstriDevCon-2019/Agenda-2019.md index 5bd1fee4fd..43cfc6d498 100644 --- a/docs/Development/Roadmap/AstriDevCon-2019/Agenda-2019.md +++ b/docs/Development/Roadmap/AstriDevCon-2019/Agenda-2019.md @@ -274,7 +274,7 @@ pageid: 42566556 - STIR/SHAKEN (maybe not "fun", but definitely important) - Missing ARI functionality? * Ability to hook dialplan applications into ARI execution flow. - * Lower transaction count necessary to setup SIP headers on outbound channels in ARI. + * Lower transaction count necessary to set up SIP headers on outbound channels in ARI. + Opus improvements - Adaptive bitrate support - Has anybody done multichannel diff --git a/docs/Development/Roadmap/AstriDevCon-2021/AstriDevcon-2021-Minutes.md b/docs/Development/Roadmap/AstriDevCon-2021/AstriDevcon-2021-Minutes.md index ae69ecd274..027a50e097 100644 --- a/docs/Development/Roadmap/AstriDevCon-2021/AstriDevcon-2021-Minutes.md +++ b/docs/Development/Roadmap/AstriDevCon-2021/AstriDevcon-2021-Minutes.md @@ -257,7 +257,7 @@ Yitzchak Pachtman - Israel, NY Based IT MSP, Ast & FreePBX for 5 years (Pitzkey) 4:20 - Joran, Timeouts on a Stasis application * To prevent a call hanging due to the application hanging. - * Prefer to not to have to wait for SIP level timers. + * Prefer not to have to wait for SIP level timers. 4:40 - J Colp, DDoS diff --git a/docs/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration.md b/docs/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration.md index aa2264be71..9a5dd2f147 100644 --- a/docs/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration.md +++ b/docs/Fundamentals/Asterisk-Configuration/Database-Support-Configuration/Realtime-Database-Configuration.md @@ -103,4 +103,4 @@ This will enable the driver to service many requests at a time, rather than seri The community provided some additional recommendations on the JIRA issue [ASTERISK-21315](https://issues-archive.asterisk.org/ASTERISK-21315): -* It is a good idea to avoid using sipregs altogether by NOT enabling it in extconfig. Using a writable sipusers table should be enough. If you cannot write to your base sipusers table because it is readonly, you could consider making a separate sipusers view that joins the readonly table with a writable sipregs table. +* It is a good idea to avoid using sipregs altogether by NOT enabling it in extconfig. Using a writable sipusers table should be enough. If you cannot write to your base sipusers table because it is readonly, you could consider making a separate sipusers view that joins the readonly table with a writable sipregs table. diff --git a/docs/Test-Suite-Documentation/index.md b/docs/Test-Suite-Documentation/index.md index c3de14ffbc..da527b7e4d 100644 --- a/docs/Test-Suite-Documentation/index.md +++ b/docs/Test-Suite-Documentation/index.md @@ -15,7 +15,7 @@ Testing of Asterisk takes primarily three forms: The Asterisk Unit Test framework exercises individual units within Asterisk in a 'white-box', 'bottom-up' approach, verifying that an individual unit maintains its interface contract with the rest of the codebase. The Asterisk Test Suite operates at the next higher level by exercising the functionality of entire modules within Asterisk and how they interact with the core of Asterisk. This is typically more of a 'black-box', 'top-down' approach, although since the typical writer of tests within the Asterisk Test Suite are developers, some knowledge of the modules under test typically occurs. Both of these tests are automated, and are executed on a frequent basis. Contrasting both of these approaches are System tests, which are typically manual and exercise the interaction of many modules in Asterisk together. System tests often occur in conjunction with initial releases of major branches and on a less frequent, periodic basis. The diagram below illustrates where each of these forms of testing fall within the larger context of a testing philosophy. Test Philosophy -Combined, the Asterisk Unit Test Framework and the Asterisk Test Suite allow the Asterisk development team to perform continuous integration, wherein changes are continually merged into the various supported branches and verified to not introduce major regressions. The unit tests and integration tests performed by these two frameworks guarantee that a basic level of functionality is not broken at any time by the introduction of a new feature or the fixing of a bug. Note that this does not mean that regressions do not occur between Asterisk versions, but that the risk associated with each check-in is reduced, and, as new tests are added, further minimized. +Combined, the Asterisk Unit Test Framework and the Asterisk Test Suite allow the Asterisk development team to perform continuous integration, wherein changes are continually merged into the various supported branches and verified not to introduce major regressions. The unit tests and integration tests performed by these two frameworks guarantee that a basic level of functionality is not broken at any time by the introduction of a new feature or the fixing of a bug. Note that this does not mean that regressions do not occur between Asterisk versions, but that the risk associated with each check-in is reduced, and, as new tests are added, further minimized. The Asterisk development team uses [Atlassian Bamboo](http://bamboo.asterisk.org/) to perform the continuous integration tests.