87 Commits (6b107e90f33fe168055f5a7a38f5237ddacfa599)

Author	SHA1	Message	Date
George Joseph	873c247f75	resource_channels.c: Fix memory leak in ast_ari_channels_external_media. ... Between ast_ari_channels_external_media(), external_media_rtp_udp(), and external_media_audiosocket_tcp(), the `variables` structure being passed around wasn't being cleaned up properly when there was a failure. * In ast_ari_channels_external_media(), the `variables` structure is now defined with RAII_VAR to ensure it always gets cleaned up. * The ast_variables_destroy() call was removed from external_media_rtp_udp(). * The ast_variables_destroy() call was removed from external_media_audiosocket_tcp(), its `endpoint` allocation was changed to to use ast_asprintf() as external_media_rtp_udp() does, and it now returns an error on failure. * ast_ari_channels_external_media() now checks the new return code from external_media_audiosocket_tcp() and sets the appropriate error response. Resolves: #1109	9 months ago
Holger Hans Peter Freyther	5e4fca062c	ari/pjsip: Make it possible to control transfers through ARI ... Introduce a ChannelTransfer event and the ability to notify progress to ARI. Implement emitting this event from the PJSIP channel instead of handling the transfer in Asterisk when configured. Introduce a dialplan function to the PJSIP channel to switch between the "core" and "ari-only" behavior. UserNote: Call transfers on the PJSIP channel can now be controlled by ARI. This can be enabled by using the PJSIP_TRANSFER_HANDLING(ari-only) dialplan function.	9 months ago
Sean Bright	a83c761c95	resource_channels.c: Explicit codec request when creating UnicastRTP. ... Fixes #394	2 years ago
Joshua C. Colp	564349ff5d	ari: Destroy body variables in channel create. ... When passing a JSON body to the 'create' channel route it would be converted into Asterisk variables, but never freed resulting in a memory leak. This change makes it so that the variables are freed in all cases. ASTERISK-30344 Change-Id: I924dbd866a01c6073e2d6fb846ccaa27ef72d49d	3 years ago
Alexander Traud	634e3ebdb8	res_ari: Fix for Doxygen. ... ASTERISK-29756 Change-Id: I2f1c1eea1c902492b77b74de9950f20ebbb7e758	4 years ago
Sungtae Kim	a1fa8df0ae	resource_channels.c: Fix external media data option ... Fixed the external media creation handle to handle the 'data' option correctly. ASTERISK-29629 Change-Id: I22e57fe8ebf3d3e08fb2121aa4a8a52cc62e8129	4 years ago
sungtae kim	79d6d222d6	resource_channels.c: Fix wrong external media parameter parse ... Fixed ARI external media handler to accept body parameters. ASTERISK-29622 Change-Id: I49509c48a6cbc0fb4165bfa4f834b5e8b9ace20d	4 years ago
Igor Goncharovsky	99d44f0c5a	res_ari: Fix audiosocket segfault ... Add check that data parameter specified when audiosocket used for externalMedia. ASTERISK-29514 #close Change-Id: Ie562f03c5d6c3835a3631f376b3d43e75b8f9617	4 years ago
sungtae kim	bbe0f2230d	res_ari: Fix create channel request channelId parameter parsing ... If channelId parameters were passed in the body, the Asterisk doesn't parsing it correctly. Fixed it to parse the channelId, other_channel_id parameter correclty. ASTERISK-28948 Change-Id: I59b49161a94869169ee19c1ffab5afcef7026157	5 years ago
sungtae kim	fa7c69f40f	res_ari: Fix create request body parameter parsing. ... If parameters were passed in the body as JSON to the create route they were not being parsed before checking to ensure that required fields were set. This change moves the parsing so it occurs before checking. ASTERISK-28940 Change-Id: I898b4c3c7ae1cde19a6840e59f498822701cf5cf	5 years ago
Joshua C. Colp	15cbff9d54	ari: Allow variables to be set on channel create. ... This change adds the same variable functionality that is available for originating a channel to the create call. Now when creating a channel you can specify dialplan variables to set instead of having to do another API call. ASTERISK-28896 Change-Id: If13997ba818136d7c070585504fc4164378aa992	6 years ago
sungtae kim	9ad3d2829c	res_ari_channels: Fixed endpoint 80 characters limit ... Fixed it to copy the entire string from the requested endpoint body except tech-prefix. ASTERISK-28847 Change-Id: I91b5f6708a1200363f3267b847dd6a0915222c25	6 years ago
Seán C McCord	163efbd724	feat: AudioSocket channel, application, and ARI support. ... This commit adds support for [AudioSocket]( https://wiki.asterisk.org/wiki/display/AST/AudioSocket), a very simple bidirectional audio streaming protocol. There are both channel and application interfaces. A description of the protocol can be found on the above referenced GitHub page. A short talk about the reasons and implementation can be found on [YouTube](https://www.youtube.com/watch?v=tjduXbZZEgI), from CommCon 2019. ARI support has also been added via the existing "externalMedia" ARI functionality. The UUID is specified using the arbitrary "data" field. ASTERISK-28484 #close Change-Id: Ie866e6c4fa13178ec76f2a6971ad3590a3a588b5	6 years ago
George Joseph	d71d0f9489	ExternalMedia: Change return object from ExternalMedia to Channel ... When we created the External Media addition to ARI we created an ExternalMedia object to be returned from the channels/externalMedia REST endpoint. This object contained the channel object that was created plus local_address and local_port attributes (which are also in the Channel variables). At the time, we thought that creating an ExternalMedia object would give us more flexibility in the future but as we created the sample speech to text application, we discovered that it doesn't work so well with ARI client libraries that a) don't have the ExternalMedia object defined and/or b) can't promote the embedded channel structure to a first-class Channel object. This change causes the channels/externalMedia REST endpoint to return a Channel object (like channels/create and channels/originate) instead of the ExternalMedia object. Change-Id: If280094debd35102cf21e0a31a5e0846fec14af9	6 years ago
George Joseph	2ae1a22e0e	ARI: External Media ... The Channel resource has a new sub-resource "externalMedia". This allows an application to create a channel for the sole purpose of exchanging media with an external server. Once created, this channel could be placed into a bridge with existing channels to allow the external server to inject audio into the bridge or receive audio from the bridge. See https://wiki.asterisk.org/wiki/display/AST/External+Media+and+ARI for more information. Change-Id: I9618899198880b4c650354581b50c0401b58bc46	6 years ago
sungtae kim	613a335de5	res/ari/resource_channels.c: Added hangup reason code for channels ... Currently, DELETE /ari/channels/<channelID> supports only few hangup reasons. It's good enough for simple use, but when it needs to set the detail reason, it comes challenges. Added reason_code query parameter for that. ASTERISK-28385 Change-Id: I1cf1d991ffd759d0591b347445a55f416ddc3ff2	6 years ago
sungtae kim	71c0c7f631	res/res_ari: Added ARI resource /ari/channels/{channelId}/rtp_statistics ... Added ARI resource for channel statistics. GET /ari/channels/{channelId}/rtp_statistics : It returns given channel's rtp statistics detail. ASTERISK-28320 Change-Id: I4343eec070438cec13f2a4f22e7fd9e574381376	7 years ago
Ben Ford	6626df586e	res_stasis: Add ability to switch applications. ... Added the ability to move between Stasis applications within Stasis. This can be done by calling 'move' in an application, providing (at minimum) the channel's id and the application to switch to. If the application is not registered or active, nothing will happen and the channel will remain in the current application, and an event will be triggered to let the application know that the move failed. The event name is "ApplicationMoveFailed", and provides the "destination" that the channel was attempting to move to, as well as the usual channel information. Optionally, a list of arguments can be passed to the function call for the receiving application. A full example of a 'move' call would look like this: client.channels.move(channelId, app, appArgs) The control object used to control the channel in Stasis can now switch which application it belongs to, rather than belonging to one Stasis application for its lifetime. This allows us to use the same control object instead of having to tear down the current one and create another. ASTERISK-28267 #close Change-Id: I43d12b10045a98a8d42541889b85695be26f288a	7 years ago
Sebastian Damm	a24bb1c4b6	res/res_ari: Add additional hangup reasons ... The ARI DELETE /channels command takes a "reason" parameter Previously, there were only five reasons implemented This patch adds more reasons to choose from for more complex setups ASTERISK-28198 #close Change-Id: I85996f1076c9946d65c778413f040a845a90fecc	7 years ago
Joshua Colp	50ac85cb40	stasis: Segment channel snapshot to reduce creation cost. ... When a channel snapshot was created it used to be done from scratch, copying all data (many strings). This incurs a cost when doing so. This change segments the channel snapshot into different components which can be reused if unchanged from the previous snapshot creation, reducing the cost. In normal cases this results in some pointers being copied with reference count being bumped, some integers being set, and a string or two copied. The other benefit is that it is now possible to determine if a channel snapshot update is redundant and thus stop it before a message is published to stasis. The specific segments in the channel snapshot were split up based on whether they are changed together, how often they are changed, and their general grouping. In practice only 1 (or 0) of the segments actually get changed in normal operation. Invalidation is done by setting a flag on the channel when the segment source is changed, forcing creation of a new segment when the channel snapshot is created. ASTERISK-28119 Change-Id: I5d7ef3df963a88ac47bc187d73c5225c315f8423	7 years ago
Joshua Colp	d0ccbb3377	stasis: Use an implementation specific channel snapshot cache. ... Channels no longer use the Stasis cache for channel snapshots. Instead they are stored in a hash table in stasis_channels which reduces the number of Stasis messages created and allows better storage. As a result the following APIs are no longer available since the stasis cache is no longer used: ast_channel_topic_cached() ast_channel_topic_all_cached() The ast_channel_cache_all() and ast_channel_cache_by_name() functions now return an ao2_container of ast_channel_snapshots rather than a container of stasis_messages therefore you can't (and don't need to) call stasis_cache functions on it. The ast_channel_topic_all() function now returns a normal topic not a cached one so you can't use stasis cache functions on it either. The ast_channel_snapshot_type() stasis message now has the ast_channel_snapshot_update structure as it's data. It contains the last snapshot and the new one. ast_channel_snapshot_get_latest() still returns the latest snapshot. The latest snapshot is now stored on the channel itself to eliminate cache hits when Stasis messages that have the snapshot as a payload are created. ASTERISK-28102 Change-Id: I9334febff60a82d7c39703e49059fa3a68825786	7 years ago
Sungtae Kim	1dea497454	res/res_ari: Fix null endpoint handle ... The res_ari(POST /channels/create handler) deos not check the endpoint parameter length. And it causes core dump. Fixed it to check the parameter length. Also fixed memory leak. ASTERISK-28169 Change-Id: Ibf10a9eb8a2e3a9ee1e13fbe748b2ecf955c3993	7 years ago
Corey Farrell	679fa5fb34	Add missing OPTIONAL_API and ARI dependences. ... I've audited all modules that include any header which includes asterisk/optional_api.h. All modules which use OPTIONAL_API now declare those dependencies in AST_MODULE_INFO using requires or optional_modules as appropriate. In addition ARI dependency declarations have been reworked. Instead of declaring additional required modules in res/ari/resource_*.c we now add them to an optional array "requiresModules" in api-docs for each module. This allows the AST_MODULE_INFO dependencies to include those missing modules. Change-Id: Ia0c70571f5566784f63605e78e1ceccb4f79c606	8 years ago
Corey Farrell	f2175c5a39	res_ari_channels: Fix reference leak in channel_state_invalid. ... channel_state_invalid leaked a reference to the channel snapshot any time it was aquired. ASTERISK-27067 #close Change-Id: I8c653f00416b39978513c5605c4be0f03b1df29a	8 years ago
Corey Farrell	a6e5bae3ef	Remove ASTERISK_REGISTER_FILE. ... ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes all traces of it. Previously exported symbols removed: * __ast_register_file * __ast_unregister_file * ast_complete_source_filename This also removes the mtx_prof static variable that was declared when MTX_PROFILE was enabled. This variable was only used in lock.c so it is now initialized in that file only. ASTERISK-26480 #close Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966	9 years ago
Mark Michelson	3bd76dd679	ARI: Add duplicate channel ID checking for channel creation. ... This is similar to what is done for origination, but for the 14 and up channel creation method. When attempting to create a channel, if a channel ID is specified and a channel already exists with that ID, then a 409 is returned. Change-Id: I77f9253278c6947939c418073b6b31065489187c	9 years ago
Mark Michelson	e459b8dadf	ARI: Detect duplicate channel IDs ... ARI and AMI allow for an explicit channel ID to be specified when originating channels. Unfortunately, there is nothing in place to prevent someone from using the same ID for multiple channels. Further complicating things, adding ID validation to channel allocation makes it impossible for ARI to discern why channel allocation failed, resulting in a vague error code being returned. The fix for this is to institute a new method for channel errors to be discerned. The method mirrors errno, in that when an error occurs, the caller can consult the channel errno value to determine what the error was. This initial iteration of the feature only introduces "unknown" and "channel ID exists" errors. However, it's possible to add more errors as needed. ARI uses this feature to determine why channel allocation failed and can return a 409 error during origination to show that a channel with the given ID already exists. ASTERISK-26421 Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06	9 years ago
Jean Aunis	91993ebaa5	resource_channels.c: add hangup reason "answered_elsewhere". ... In ARI, the channels API allows to hangup a channel with a hangup reason. This commit adds a new reason "answered_elsewhere". When using a SIP channel, this will eventually allow Asterisk to add a proper "Reason" header to a CANCEL message. ASTERISK-26321 Change-Id: Ia97675bd4acd6a7f58eb467953dfb94559f6583d	9 years ago
George Joseph	886f2cab23	rest_api/channels: Fix multiple issues with create and dial ... * We weren't properly subscribing to the channel and it's originator on create. * We weren't doing a publish_dial after calling ast_call on dial. * We weren't calling depart_bridge when a channel left the dial bridge. The first 2 issues were causing events to not be generated and the third was actually causing channels to not get properly destroyed when hung up. Together these 3 issues were causing the new rest_apichannels/create_dial_bridge tests to fail. As a result of the fixes, the cdr state machine had to be slightly tweaked to allow bridge leave events without asserting and the tests themselves had to be updated to account for the channels now cleaning themselves up. Change-Id: Ibf23abf5a62de76e82afb4461af5099c961b97d8	9 years ago
zuul	39e6d80937	Merge "ARI: Ensure proper channel state on operations."	10 years ago
Mark Michelson	1fd3a7849e	ARI: Ensure proper channel state on operations. ... ARI was recently outfitted with operations to create and dial channels. This leads to the ability to try funny stuff. You could create a channel and then immediately try to play back media on it. You could create a channel, dial it, and while it is ringing attempt to make it continue in the dialplan. This commit attempts to fix this by adding a channel state check to operations that should not be able to operate on outbound channels that have not yet answered. If a channel is in an invalid state, we will send a 412 response. ASTERISK-26047 #close Reported by Mark Michelson Change-Id: I2ca51bf9ef2b44a1dc5a73f2d2de35c62c37dfd8	10 years ago
Joshua Colp	643dd462ee	Merge "ari/resource_channels: Add 'formats' to channel create/originate"	10 years ago
George Joseph	a2f820e8dc	ari/resource_channels: Add 'formats' to channel create/originate ... If you create a local channel and don't specify an originator channel to take capabilities from, we automatically add all audio formats to the new channel's capabilities. When we try to make the channel compatible with another, the "best format" functions pick the best format available, which in this case will be slin192. While this is great for preserving quality, it's the worst for performance and overkill for the vast majority of applications. In the absense of any other information, adding all formats is the correct thing to do and it's not always possible to supply an originator so a new parameter 'formats' has been added to the channel create/originate functions. It's just a comma separated list of formats to make availalble for the channel. Example: "ulaw,slin,slin16". 'formats' and 'originator' are mutually exclusive. To facilitate determination of format names, the format name has been added to "core show codecs". ASTERISK-26070 #close Change-Id: I091b23ecd41c1b4128d85028209772ee139f604b	10 years ago
zuul	84a93b0d67	Merge "ARI: Re-implement the ARI dial command, allowing for early bridging."	10 years ago
Mark Michelson	88d997913f	ARI: Re-implement the ARI dial command, allowing for early bridging. ... ARI dial had been implemented using the Dial API. This made great sense when dialing was 100% separate from bridging. However, if a channel were to be added to a bridge during the dial attempt, there would be a conflict between the dialing thread and the bridging thread. Each would be attempting to read frames from the dialed channel and act on them. The initial attempt to make the two play nice was to have the Dial API suspend the channel in the bridge and stay in charge of the channel until the dial was complete. The problem with this was that it was riddled with potential race conditions. It also was not well-suited for the case where the channel changed which bridge it was in during the dial. This new approach removes the use of the Dial API altogether. Instead, the channel we are dialing is placed into an invisible ARI dialing bridge. The bridge channel thread handles incoming frames from the channel. If the channel is added to a real bridge, it is departed from the invisible bridge and then added to the real bridge. Similarly, if the channel is removed from the real bridge, it is automatically added back to the invisible bridge if the dial attempt is still active. This approach keeps the threading simple by always having the channel being handled by bridge channel threads. ASTERISK-25925 Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb	10 years ago
Matt Jordan	03d88b5656	ARI: Add the ability to play multiple media URIs in a single operation ... Many ARI applications will want to play multiple media files in a row to a resource. The most common use case is when building long-ish IVR prompts made up of multiple, smaller sound files. Today, that requires building a small state machine, listening for each PlaybackFinished event, and triggering the next sound file to play. While not especially challenging, it is tedious work. Since requiring developers to write tedious code to do normal activities stinks, this patch adds the ability to play back a list of media files to a resource. Each of the 'play' operations on supported resources (channels and bridges) now accepts a comma delineated list of media URIs to play. A single Playback resource is created as a handle to the entire list. The operation of playing a list is identical to playing a single media URI, save that a new event, PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final media URI. When the entire list is finished being played, a PlaybackFinished event is raised. In order to help inform applications where they are in the list playback, the Playback resource now includes a new, optional attribute, 'next_media_uri', that contains the next URI in the list to be played. It's important to note the following: - If an offset is provided to the 'play' operations, it only applies to the first media URI, as it would be weird to skip n seconds forward in every media resource. - Operations that control the position of the media only affect the current media being played. For example, once a media resource in the list completes, a 'reverse' operation on a subsequent media resource will not start a previously completed media resource at the appropiate offset. - This patch does not add any new operations to control the list. Hopefully, user feedback and/or future patches would add that if people want it. ASTERISK-26022 #close Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f	10 years ago
Sean Bright	14938184a3	res_ari: Correct Location headers returned by some ARI resources ... The Location headers returned by: * /bridges/{bridgeId}/play * /bridges/{bridgeId}/record * /channels/{channelId}/play * /channels/{channelId}/record Did not have the '/ari' prefix, and in the case of the 'play' resources, were using 'playback' instead of 'playbacks.' Change-Id: I957c58a3a1471bf477dae7c67faa1b74fcd9241c	10 years ago
Mark Michelson	abbb2edd4c	ARI: Add method to Dial a created channel. ... This adds a new ARI method that allows for you to dial a channel that you previously created in ARI. By combining this with the create method for channels, it allows for a workflow where a channel can be created, manipulated, and then dialed. The channel is under control of the ARI application during all stages of the Dial and can even be manipulated based on channel state changes observed within an ARI application. The overarching goal for this is to eventually be able to add a dialed channel to a Stasis bridge earlier than the "Up" state. However, at the moment more work is needed in the Dial and Bridge APIs in order to facilitate that. ASTERISK-25889 #close Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205	10 years ago
Mark Michelson	dd48d60c5b	ARI: Add method to create a new channel. ... This adds a new ARI method to the channels resource that allows for the creation of a new channel. The channel is created and then placed into the specified Stasis application. This is different from the existing originate method that creates a channel, dials it, and then places the answered channel into the dialplan or a Stasis application. This method does not attempt to call the channel at all. Dialing is left as a later step after channel creation. This allows for pre-dialing channel manipulation if desired. ASTERISK-25889 Change-Id: I3c96a0aba914b08e39f6256371a5bd4c92cbded8	10 years ago
Corey Farrell	f226bd6f60	ARI: Fix missing dependencies. ... ARI modules that are generated by 'make ari-stubs' are all dependent on res_ari_model. Additionally some of the same modules depend on one or more res_stasis_* modules. ASTERISK-25027 #close Reported by: Corey Farrell Change-Id: I8e07fe7e81fedacb87232f2b6f8b5f47927b4153	11 years ago
Matt Jordan	4a58261694	git migration: Refactor the ASTERISK_FILE_VERSION macro ... Git does not support the ability to replace a token with a version string during check-in. While it does have support for replacing a token on clone, this is somewhat sub-optimal: the token is replaced with the object hash, which is not particularly easy for human consumption. What's more, in practice, the source file version was often not terribly useful. Generally, when triaging bugs, the overall version of Asterisk is far more useful than an individual SVN version of a file. As a result, this patch removes Asterisk's support for showing source file versions. Specifically, it does the following: * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and remove passing the version in with the macro. Other facilities than 'core show file version' make use of the file names, such as setting a debug level only on a specific file. As such, the act of registering source files with the Asterisk core still has use. The macro rename now reflects the new macro purpose. * main/asterisk: - Refactor the file_version structure to reflect that it no longer tracks a version field. - Remove the "core show file version" CLI command. Without the file version, it is no longer useful. - Remove the ast_file_version_find function. The file version is no longer tracked. - Rename ast_register_file_version/ast_unregister_file_version to ast_register_file/ast_unregister_file, respectively. * main/manager: Remove value from the Version key of the ModuleCheck Action. The actual key itself has not been removed, as doing so would absolutely constitute a backwards incompatible change. However, since the file version is no longer tracked, there is no need to attempt to include it in the Version key. * UPGRADE: Add notes for: - Modification to the ModuleCheck AMI Action - Removal of the "core show file version" CLI command Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e	11 years ago
Matthew Jordan	ea0098724e	clang compiler warnings: Fix autological comparisons ... This fixes autological comparison warnings in the following: * chan_skinny: letohl may return a signed or unsigned value, depending on the macro chosen * func_curl: Provide a specific cast to CURLoption to prevent mismatch * cel: Fix enum comparisons where the enum can never be negative * enum: Fix comparison of return result of dn_expand, which returns a signed int value * event: Fix enum comparisons where the enum can never be negative * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be negative * presencestate: Use the actual enum value for INVALID state * security_events: Fix enum comparisons where the enum can never be negative * udptl: Don't bother to check if the return value from encode_length is less than 0, as it returns an unsigned int * translate: Since the parameters are unsigned int, don't bother checking to see if they are negative. The cast to unsigned int would already blow past the matrix bounds. * res_pjsip_exten_state: Use a temporary value to cache the return of ast_hint_presence_state * res_stasis_playback: Fix enum comparisons where the enum can never be negative * res_stasis_recording: Add an enum value for the case where the recording operation is in error; fix enum comparisons * resource_bridges: Use enum value as opposed to -1 * resource_channels: Use enum value as opposed to -1 Review: https://reviewboard.asterisk.org/r/4533 ASTERISK-24917 Reported by: dkdegroot patches: rb4533.patch submitted by dkdegroot (License 6600) ........ Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	9e841e4fb6	ARI: Fix crash if integer values used in JSON payload 'variables' object. ... Sending the following ARI commands caused Asterisk to crash if the JSON body 'variables' object passes values of types other than strings. POST /ari/channels POST /ari/channels/{channelid} PUT /ari/endpoints/sendMessage PUT /ari/endpoints/{tech}/{resource}/sendMessage * Eliminated RAII_VAR usage in ast_ari_channels_originate_with_id(), ast_ari_channels_originate(), ast_ari_endpoints_send_message(), and ast_ari_endpoints_send_message_to_endpoint(). ASTERISK-24751 #close Reported by: jeffrey putnam Review: https://reviewboard.asterisk.org/r/4447/ ........ Merged revisions 432404 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432405 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	a528dfc9a7	ARI/PJSIP: Apply requesting channel's format cap to created channels ... This patch addresses the following problems: * ari/resource_channels: In ARI, we currently create a format capability structure of SLIN and apply it to the new channel being created. This was originally done when the PBX core was used to create the channel, as there was a condition where a newly created channel could be created without any formats. Unfortunately, now that the Dial API is being used, this has two drawbacks: (a) SLIN, while it will ensure audio will flows, can cause a lot of needless transcodings to occur, particularly when a Local channel is created to the dialplan. When no format capabilities are available, the Dial API handles this better by handing all audio formats to the requsted channels. As such, we defer to that API to provide the format capabilities. (b) If a channel (requester) is causing this channel to be created, we currently don't use its format capabilities as we are passing in our own. However, the Dial API will use the requester channel's formats if none are passed into it, and the requester channel exists and has format capabilities. This is the "best" scenario, as it is the most likely to create a media path that minimizes transcoding. Fixing this simply entails removing the providing of the format capabilities structure to the Dial API. * chan_pjsip: Rather than blindly picking the first format in the format capability structure - which actually *can* be a video or text format - we select an audio format, and only pick the first format if that fails. That minimizes the weird scenario where we attempt to transcode between video/audio. * res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure. Since ast_request already limits us down to one format capability once the format capabilities are passed along, there's no reason to squelch it here. * channel: Fixed a comment. The reason we have to minimize our requested format capabilities down to a single format is due to Asterisk's inability to convey the format to be used back "up" a channel chain. Consider the following: PJSIP/A => L;1 <=> L;2 => PJSIP/B g,u,a g,u,a g,u,a u That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local channel has inherited those format capabilities down the line; PJSIP/B supports only ulaw. According to these format capabilities, ulaw is acceptable and should be selected across all the channels, and no transcoding should occur. However, there is no way to convey this: when L;2 and PJSIP/B are put into a bridge, we will select ulaw, but that is not conveyed to PJSIP/A and L;1. Thus, we end up with: PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B g g X u u Which causes g722 to be written to PJSIP/B. Even if we can convey the 'ulaw' choice back up the chain (which through some severe hacking in Local channels was accomplished), such that the chain looks like: PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B u u u u We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back with only 'ulaw'. This results in all the channel structures being set up correctly, but PJSIP/A *still* sending g722 and causing the chain to fall apart. There's a lot of difficulty just in setting this up, as there are numerous race conditions in the act of bridging, and no clean mechanism to pass the selected format backwards down an established channel chain. As such, the best that can be done at this point in time is clarifying the comment. Review: https://reviewboard.asterisk.org/r/4434/ ASTERISK-24812 #close Reported by: Matt Jordan ........ Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	bedf51b2ce	res_ari_channels: Return a 404 response when a requested channel variable does not exist. ... This change makes it so that if a channel variable is requested and it does not exist a 404 response will be returned instead of an allocation failed response. This makes it easier to debug and figure out what is going on for a user. ASTERISK-24677 #close Reported by: Joshua Colp ........ Merged revisions 432154 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432155 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	29f66b0429	ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app ... This patch adds a new feature to ARI to redirect a channel to another server, and fixes a few bugs in PJSIP's handling of the Transfer dialplan application/ARI redirect capability. *New Feature* A new operation has been added to the ARI channels resource, redirect. With this, a channel in a Stasis application can be redirected to another endpoint of the same underlying channel technology. *Bug fixes* In the process of writing this new feature, two bugs were fixed in the PJSIP stack: (1) The existing .transfer channel callback had the limitation that it could only transfer channels to a SIP URI, i.e., you had to pass 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is still supported, it is somewhat unintuitive - particularly in a world full of endpoints. As such, we now also support specifying the PJSIP endpoint to transfer to. (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by updating its Contact header. Alas, that resulted in the forwarding destination set by the dialplan application/ARI resource/whatever being rewritten with very incorrect information. Hence, we now don't bother updating an outgoing response if it is a 302. Since this took a looong time to find, some additional debug statements have been added to those modules that update the Contact headers. Review: https://reviewboard.asterisk.org/r/4316/ ASTERISK-24015 #close Reported by: Private Name ASTERISK-24703 #close Reported by: Matt Jordan ........ Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	858e825568	res/ari/resource_channels: Add missing 'no_answer' reason to DELETE /channels ... One of the canonical reasons for hanging up a channel is because the far end failed to answer - or because someone else answered, and we want to get rid of this channel. This patch adds the missing value to the 'reason' query parameter for the DELETE /channels operation. Review: https://reviewboard.asterisk.org/r/4400 ASTERISK-24745 #close Reported by: Ben Merrills patches: add_no_answer_ari_hangup_cause.diff uploaded by Ben Merrills (License 6678) ........ Merged revisions 431622 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431623 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	7f836c1c15	Add the ability to continue and originate using priority labels. ... With this patch, the following two ARI commands POST /channels POST /channels/{id}/continue Accept a new parameter, label, that can be used to continue to or originate to a priority label in the dialplan. Because this is adding a new parameter to ARI commands, the API version of ARI has been bumped from 1.6.0 to 1.7.0. This patch comes courtesy of Nir Simionovich from Greenfield Tech. Thanks! ASTERISK-24412 #close Reported by Nir Simionovich Review: https://reviewboard.asterisk.org/r/4285 ........ Merged revisions 430337 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430338 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	60ab564ad2	ari: Add support for specifying an originator channel when originating. ... If an originator channel is specified when originating a channel the linked ID of it will be applied to the newly originated outgoing channel. This allows an association to be made between the two so it is known that the originator has dialed the originated channel. ASTERISK-24552 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4243/ ........ Merged revisions 429153 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429154 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	bb494067a5	Multiple revisions 421311-421312 ... ........ r421311 | mjordan | 2014-08-17 20:11:28 -0500 (Sun, 17 Aug 2014) | 9 lines res/ari/resource_channels: Don't return allocation failure on failed function If a function fails to execute, it is most likely due to one of two reasons: (1) The function doesn't exist or can't be read from (2) The function is dangerous and is restricted based on the user's permissions Currently we return allocation failure, which is incorrect. This updates the reason code to more accurately reflect why the request failed. ASTERISK-24215 ........ r421312 | mjordan | 2014-08-17 20:13:41 -0500 (Sun, 17 Aug 2014) | 4 lines res/ari/resource_channels: Fix compilation issue Forgot a parameter. Whoops. ........ Merged revisions 421311-421312 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421313 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago