[Home]

Summary:ASTERISK-22768: ARI: Originating multiple channels using POST /channels in succession causes orphaned channels; other problems
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2013-10-25 10:55:05Date Closed:2013-11-01 07:34:25
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Channels Resources/res_ari
Versions:12.0.0-beta1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:{quote}
This problem occurs on latest trunk, and was first noticed on trunk from about two days ago.

I've got some code that originates a bunch of calls at once using POST /channels.

If I do this with two channels, it seems to always work - I get http responses for the POST, and the phones ring.

With three channels, it sometimes works once or twice, but eventually one or more of the POST requests never receive a response, and the phones never ring.  I think after the first time a phone fails to ring, it won't ring again on future attempts.

The channels *do* get created; doing action: status in AMI shows channels like this:

{noformat}
Event: Status
Privilege: Call
Type: SIP
DNID:
EffectiveConnectedLineNum: <unknown>
EffectiveConnectedLineName: <unknown>
TimeToHangup: 0
BridgeID:
Linkedid: 1382555886.10
Application: AppDial2
Data: (Outgoing Line)
Nativeformats: (ulaw|h263)
Readformat: ulaw
Readtrans:
Writeformat: ulaw
Writetrans:
Callgroup: 0
Pickupgroup: 0
Seconds: 357
Channel: SIP/1001-0000000a
ChannelState: 0
ChannelStateDesc: Down
CallerIDNum: <unknown>
CallerIDName: <unknown>
ConnectedLineNum: <unknown>
ConnectedLineName: <unknown>
AccountCode:
Context: phones
Exten:
Priority: 1
Uniqueid: 1382555886.10
{noformat}

These don't ever seem to clear up.

POST urls look like

{noformat}
/ari/channels?endpoint=SIP%2F1005&context=&extension=&priority=&app=queue&appArgs=remote&subscribeApp=queue&callerId=&timeout=30
{noformat}

{quote}

We should create a test for ARI that does a number of originates in succession (pick some large number) and verifies:
# That each request gets an expected response
# That the channels are created successfully and all events are received
# That the channels are 'answered' by a device (Asterisk or SIPp) and that the channels are put into the Stasis application
Comments: