I’m trying to stress a stasis application![stasis_app|690x86] with multiple concurrent sip sessions with sipp. The application creates a bridge when receives a call to a destination given as parameter like:
exten => 7000,1,NoOp()
same => n,Answer()
same => n,Stasis(cac,inbound,SIP/alice)
same => n,Hangup()
(upload://tZXbTOTPlNsVdWYfD4V3JdpWWaI.png)
The cac applications is registered without issues. But what I’m trying to do is to call to an extension that answer with an audio file in order to test several concurrent sessions at the same time. And here is where I have this conceptual problem, I am testing with the 1000 extension that came by default in asterisk:
Example:
same => n,Stasis(cac,inbound,1000)
And I receive a not found answer (sipp -d 10000 -s 1000 asterisk-ip -l 5)
So the questions would be, how can I give an extension as parameter of a stasis app? I understand that the problem is that originate dont accept extensions destination for the communication, there is a way that accepts it?
Since you are testing stasis performance the suggestion is to use ARI channel/media calls, not another extension, to facilitate media playback on the channel. Remember the concept here with stasis/ARI is to build your own application outside of the dialplan.
On a personal aside from my own load testing, I don’t know what level of scale you are looking to achieve however for my uses the apps directly connecting to Asterisk ARI websockets are literally just pushing events out asynchronously as webhook POSTs to my actual applications which I load balance behind haproxy. This mostly grew out of only 1 instance of each app being able to receive events from ARI/stasis at a time which meant making changes to my apps had way more impact potential than was acceptable. Now I can use the load balancers to slowly introduce my changes to see if testing missed anything and I rarely touch that small portion of the data flow except for adding instrumentation.
My approach admittedly adds more complexity and more moving parts but was necessary for my scaling/availability needs. It also means my Asterisk deploys are fairly static and simple since all the dialplan logic is external. The less I touch Asterisk configs, the better.
Endpoints have to be prefixed with their technology. Rather than POST with query parameters endpoint=1000, you should probably POST with endpoint=SIP/1000 - assuming you want to dial out using chan_sip.
If you want to access an extension, in the sense that Asterisk uses the term, you should originate toLocal/<extension>@<context> or Local/<extension> for the default context.
