summaryrefslogtreecommitdiff
path: root/main/bridge_channel.c
diff options
context:
space:
mode:
authorMark Michelson <mmichelson@digium.com>2016-05-09 15:00:56 -0500
committerMark Michelson <mmichelson@digium.com>2016-05-31 11:43:24 -0500
commit205a31f86c4ceec4966492363fb9ac674c990235 (patch)
tree425d8f23f52900292cd7aad1e1f7f75bdd5a55d3 /main/bridge_channel.c
parent88d997913faabe81f8b9e7bdaa56742be0d669b9 (diff)
Expand the scope of Dial Events
Dial events up to this point have come in two flavors * A Dial event with no status to indicate that dialing has begun * A Dial event with a status to indicate that dialing has ended With this change, Dial events have been expanded to also give intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS". This is especially useful for ARI dialing, as it gives the application writer the opportunity to place a channel into an early bridge when early media is detected. AMI handles these in-progress dial events by sending a new event called "DialState" that simply indicates that dial state has changed but has not ended. ARI never distinguished between DialBegin and DialEnd, so no change was made to the event itself. Another change here relates to dial forwards. A forward-related event was previously only sent when a channel was successfully able to forward a call to a new channel. With this set of changes, if forwarding is blocked, we send a Dial event with a forwarding destination but no forwarding channel, since we were prevented from creating one. This is again useful for ARI since application writers can now handle call forward attempts from within their own application. ASTERISK-25925 #close Reported by Mark Michelson Change-Id: I42cbec7730d84640a434d143a0d172a740995543
Diffstat (limited to 'main/bridge_channel.c')
-rw-r--r--main/bridge_channel.c29
1 files changed, 29 insertions, 0 deletions
diff --git a/main/bridge_channel.c b/main/bridge_channel.c
index db4ecfe57..6766dff8e 100644
--- a/main/bridge_channel.c
+++ b/main/bridge_channel.c
@@ -2393,6 +2393,14 @@ static struct ast_frame *bridge_handle_dtmf(struct ast_bridge_channel *bridge_ch
return frame;
}
+static const char *controls[] = {
+ [AST_CONTROL_RINGING] = "RINGING",
+ [AST_CONTROL_PROCEEDING] = "PROCEEDING",
+ [AST_CONTROL_PROGRESS] = "PROGRESS",
+ [AST_CONTROL_BUSY] = "BUSY",
+ [AST_CONTROL_CONGESTION] = "CONGESTION",
+ [AST_CONTROL_ANSWER] = "ANSWER",
+};
/*!
* \internal
@@ -2404,6 +2412,17 @@ static void bridge_handle_trip(struct ast_bridge_channel *bridge_channel)
{
struct ast_frame *frame;
+ if (!ast_strlen_zero(ast_channel_call_forward(bridge_channel->chan))) {
+ /* TODO If early bridging is ever used by anything other than ARI,
+ * it's important that we actually attempt to handle the call forward
+ * attempt, as well as expand features on a bridge channel to allow/disallow
+ * call forwarding. For now, all we do is raise an event, showing that
+ * a call forward is being attempted.
+ */
+ ast_channel_publish_dial_forward(NULL, bridge_channel->chan, NULL, NULL, "CANCEL",
+ ast_channel_call_forward(bridge_channel->chan));
+ }
+
if (bridge_channel->features->mute) {
frame = ast_read_noaudio(bridge_channel->chan);
} else {
@@ -2417,10 +2436,20 @@ static void bridge_handle_trip(struct ast_bridge_channel *bridge_channel)
switch (frame->frametype) {
case AST_FRAME_CONTROL:
switch (frame->subclass.integer) {
+ case AST_CONTROL_CONGESTION:
+ case AST_CONTROL_BUSY:
+ ast_channel_publish_dial(NULL, bridge_channel->chan, NULL, controls[frame->subclass.integer]);
+ break;
case AST_CONTROL_HANGUP:
ast_bridge_channel_kick(bridge_channel, 0);
bridge_frame_free(frame);
return;
+ case AST_CONTROL_RINGING:
+ case AST_CONTROL_PROGRESS:
+ case AST_CONTROL_PROCEEDING:
+ case AST_CONTROL_ANSWER:
+ ast_channel_publish_dial(NULL, bridge_channel->chan, NULL, controls[frame->subclass.integer]);
+ break;
default:
break;
}