本文深入探讨了在asterisk环境下，使用php agi脚本实现异步执行和精细通道控制所面临的挑战。文章指出agi（asterisk gateway interface）本质上是一个同步接口，无法满足真正的异步并发需求。为解决此问题，文章强烈推荐使用ami（asterisk manager interface）或ari（asterisk rest interface）作为实现异步操作和通道管理的核心工具，并简要提及了agi中`wait()`和`answer()`的使用场景及局限性。
引言：Asterisk中PHP脚本的异步执行与通道控制挑战
在Asterisk通信系统中，开发者经常需要通过外部脚本（如PHP）来处理呼叫逻辑。PHP AGI（Asterisk Gateway Interface）是实现这一目标的一种常见方式。然而，当面临需要同时执行多个AGI脚本（即异步并发）并能按需终止特定正在运行的通道时，开发者可能会发现AGI的固有特性带来了挑战。本文将详细解析AGI的同步机制，并介绍实现异步执行和精细通道控制的推荐方案。
理解AGI的同步执行机制
AGI（Asterisk Gateway Interface）是Asterisk与外部应用程序交互的一种协议。其核心特性是同步。这意味着当一个Asterisk通道（channel）进入AGI应用程序时，该通道将阻塞，直到AGI脚本执行完毕并返回控制权给Asterisk。
开发者尝试使用console dial或channel originate命令来启动多个AGI脚本，并期望它们能异步运行，但往往会遇到问题。
考虑以下PHP AGI脚本示例（demo.php）：
立即学习“PHP免费学习笔记（深入）”；
#!/usr/bin/php -q
verbose("................Demo.......................");
sleep((int)$timeParameter*100); // 模拟耗时操作
$agi->verbose("................Demo1.......................");
?>以及相应的拨号方案（extensions.conf）：
[demo_3] exten => 003,1,AGI(demo.php,3) [demo_4] exten => 004,1,AGI(demo.php,4)
当通过asterisk -rx "console dial 003@demo_3"命令发起呼叫时，Asterisk会启动一个通道，并将其交给demo.php脚本处理。如果此时再次尝试asterisk -rx "console dial 004@demo_4"，你会发现第二个呼叫并不会立即并发执行，而是会等待第一个呼叫的AGI脚本完成，或者在Asterisk内部排队处理，这并非真正的异步。
即使使用channel originate命令，例如：
asterisk -rx "channel originate local/003@demo_3 extension 104@from-internal" asterisk -rx "channel originate local/004@demo_4 extension 104@from-internal"
这些命令确实可以创建多个独立的通道并让它们进入各自的AGI脚本。然而，每个通道一旦进入AGI，仍然会被其对应的demo.php脚本同步阻塞。这意味着，如果demo.php脚本中有一个sleep(400)的命令，那么即使你通过channel originate创建了多个通道，每个通道的AGI脚本仍然会等待400秒。你无法通过外部命令（如channel request hangup local/003@demo_3）直接控制一个正在被AGI脚本阻塞的通道，因为AGI脚本正在“拥有”该通道的控制权。
AGI在异步操作与通道控制上的局限性
从上述分析可以看出，AGI接口并非为异步操作和外部精细通道控制而设计。它的主要职责是在一个特定的呼叫流程中，为外部应用程序提供一个与Asterisk交互的同步点。如果需要以下功能，AGI将无法直接满足：
- 真正的异步并发执行：在不阻塞主控流程的情况下，同时启动多个任务。
- 外部通道管理：在AGI脚本执行过程中，从外部（如另一个脚本或控制台）主动挂断、转移或修改特定通道的状态。
- 事件驱动编程：根据Asterisk系统发生的事件（如新呼叫、通道挂断等）触发外部应用程序的逻辑。
实现异步执行与精细通道控制的推荐方案
为了实现真正的异步执行和对Asterisk通道的精细控制，我们应该转向使用Asterisk提供的更高级的接口：AMI（Asterisk Manager Interface）和ARI（Asterisk REST Interface）。
1. Asterisk Manager Interface (AMI)
AMI是一个基于TCP连接的接口，允许外部应用程序与Asterisk进行实时通信。它通过发送Action命令和接收Event事件来实现对Asterisk的全面管理。
如何实现异步执行与通道控制：
- 异步呼叫发起： 外部应用程序可以通过AMI的Originate Action命令来发起新的呼叫，而无需阻塞应用程序自身的执行流程。AMI客户端可以立即返回，并等待Asterisk通过NewChannel、Dial、Hangup等事件报告呼叫进度。
- 通道控制： AMI提供了Hangup Action来终止特定通道，Redirect Action来转移通道，以及其他Action来查询通道状态或修改通道属性。这些操作可以在任何时间由外部应用程序发起，独立于AGI脚本的执行。
- 事件驱动： AMI客户端可以订阅各种Asterisk事件，从而实现事件驱动的异步逻辑。例如，当一个呼叫挂断时，AMI客户端会收到Hangup事件，然后可以触发相应的清理或日志记录操作。
使用AMI，你的PHP应用程序可以作为AMI客户端运行，通过AMI库（如php-asterisk-ami等）连接到Asterisk，并发送各种管理命令。
2. Asterisk REST Interface (ARI)
ARI是一个更现代、基于RESTful HTTP和WebSocket的接口，专为构建Stasis应用程序而设计。Stasis应用程序是一种完全由外部应用程序控制的Asterisk应用程序。
如何实现异步执行与通道控制：
- Stasis应用程序： 通过将通道置于Stasis应用程序中，外部应用程序可以完全控制通道的生命周期和行为。ARI允许应用程序通过HTTP请求发起呼叫、接听、挂断、桥接等操作。
- WebSocket事件： ARI通过WebSocket提供实时事件流，外部应用程序可以监听这些事件来响应Asterisk中的变化，从而实现高度异步和事件驱动的交互。
- 资源导向： ARI将Asterisk中的通道、桥接、录音等都视为RESTful资源，通过标准的HTTP方法（GET, POST, PUT, DELETE）进行操作，使得开发更加直观。
对于新的项目，ARI通常是更推荐的选择，因为它更符合现代Web服务的开发范式。
AGI的替代性考虑与注意事项（如果必须使用AGI）
尽管AMI和ARI是实现异步和精细控制的优选方案，但在某些受限场景下，如果仍需使用AGI，可以考虑以下几点，但请注意它们并非真正的异步解决方案：
-
使用Wait()命令： 在AGI脚本中，你可以使用Wait()命令让Asterisk等待一段时间，而不是让PHP脚本自身通过sleep()阻塞。例如：
$agi->exec('Wait', '100'); // 让Asterisk等待100秒然而，这仍然是同步阻塞当前通道的。通道在等待期间不会执行其他操作。
-
先Answer()呼叫： 如果你的AGI脚本需要长时间运行，并且呼叫是从外部发起（例如，一个响铃的电话），务必在AGI脚本开始执行耗时操作之前调用Answer()命令：
$agi->answer(); // 接听呼叫 $agi->exec('Wait', '400'); // 或其他耗时操作如果不先接听呼叫，呼叫方可能会因为长时间无人接听而超时挂断，导致你的AGI脚本在完成前通道就被终止。
AGI作为AMI/ARI的辅助： 可以在AMI/ARI应用程序中发起一个呼叫，并将其引导至一个简单的AGI脚本，该脚本只负责收集少量用户输入或执行非常快速的逻辑，然后将控制权交还给AMI/ARI应用程序。这样可以利用AGI的简单性处理特定环节，而将复杂的异步逻辑和通道控制交给AMI/ARI。
总结
在Asterisk环境中实现PHP脚本的异步执行和对通道的精细控制，AGI并非理想选择，因为它本质上是一个同步接口。对于需要多并发、非阻塞操作和外部通道管理的场景，强烈建议采用AMI（Asterisk Manager Interface）或ARI（Asterisk REST Interface）。它们提供了更强大的功能和更灵活的编程模型，能够满足复杂的通信应用需求。如果受限于AGI，虽然可以使用Wait()和Answer()等命令，但需清楚这些方法仍是阻塞的，无法提供真正的异步体验。正确选择和使用Asterisk的接口，是构建健壮和高效通信系统的关键。
