Use use a local channel on the channel side of originate.
For the avoidance of doubt, making an extension do paging/intercom is a question of custom dialplan programming, so I’m assuming that you have done that and that context ???, extension 5003, priority 1 will achieve the desired effect.
The Channel parameter would typically be something like Local/s@inbound_context, or perhaps PJSIP/endpoint to connect the inbound end to a local extension. For example, if you add something like this to your extensions.conf (assuming the default [time] context is already there):
include => time
exten => s,1,Verbose(Entering speaking clock)
exten => s,n,Goto(time,11,time)
Then you can try Local/s@speaking-clock as your Channel.
You have to capture the channel instance name, from the events, when the channel is created. The instance name has -<instance>;<direction> appended to base name, where instance is an, opaque, number, and direction is 1 or 2 depending on whether it is the side that was initially created or the side that initially ran dialplan.
If you don’t use /n, you can also have the channel being optimised out in which case you have to detect the real channel that is doing the work. As far as I can remember, a bridge has to be created before optimisation occurs, so it probably won’t occur here, however it might still be better to determine the real channel and hang that up.
well, I can’t capture new created channels because:
1- paging call create a new channel for each ext., so I have to terminate all, one by one.
2- new calls between system users and from/ to trunk expected and capturing new channels will collect all including those calls are not belong to the paging call
Here’s another of those wonderful cases of confusing Asterisk terminology.
The “channel” parameter on the Originate action is a specification of the context and extension to terminate that end of the call (as above). But when the call is set up, Asterisk creates two (maybe three, maybe more?) dynamic “channel” objects to represent the ends of the call connection. These have unique names, which are roughly related to the “context” and “channel” parameters on the Originate.
But determining exactly which “channel” objects belong to your Originate request (as opposed to other calls which might also be in progress concurrently) is slightly tricky. You have to listen to the sequence of event notifications, looking for ones mentioning the number you were trying to call, and work out the relationships from there.
I have done this kind of thing in various hacky ways, and I can never quite be sure how reliable the result is.
I suspect this is because Asterisk was originally designed for circuit switched systems, where there could only be one channel, as currently defined by the Asterisk core, associated with one channel, as supplied to originate. VoIP and local channels mean this is no longer true, but, I think the terminology has been kept, in some places.
There is no channel created dependent on the context parameter. A channel is created based on the Channel parameter. If this is an external channel, that is the only channel that is created.
Here there is a local channel, for which Asterisk always generates two channels, using suffix ;1 and ;2. Anything written into one, comes out of the other, in both directions. the ;2 one starts running the dialplan provided in the data part of the parameter.
Typically, when used with Originate, the ;2 local channel then uses Dial to invoke an external channel, whose base name is determined by the dialplan, not directly by Originate.