[asterisk-bugs] [JIRA] (ASTERISK-22768) ARI: Originating multiple channels using POST /channels in succession causes orphaned channels; other problems
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Fri Oct 25 10:58:03 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-22768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan updated ASTERISK-22768:
-----------------------------------
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
was:
{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 (say, 25?) 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
> ARI: Originating multiple channels using POST /channels in succession causes orphaned channels; other problems
> --------------------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-22768
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-22768
> Project: Asterisk
> Issue Type: Bug
> Components: Core/Channels, Resources/res_ari
> Reporter: Matt Jordan
>
> {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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list