Summary:ASTERISK-02373: Asterisk Manager response corruption.
Reporter:dw (dw)Labels:
Date Opened:2004-09-09 09:26:11Date Closed:2008-01-15 15:07:11.000-0600
Versions:Frequency of
Description:Possibly a locking issue - I have some code here that waits for an event, queries the variable on that event's channel, then Redirects the channel.

My problem is, sometimes, but not every time (about 1 in 5), a Newexten event will get mixed in with the result of my Getvar call, leaving the output inconsistent.

I assume it has to do with locking as although responses are getting mixed together, data sent as part of a single write(2) call is not mixed up (guaranteed to be atomic up to 1024 bytes under POSIX IIRC). Additional information contains an example of the problem.

I am willing to hunt for the relevant missing locks and fix the problem, but it will take me time, and this might be trivial for you to fix. Let me know if a patch from me would be preferred. Thanks.


<<< ------------------------<<<
Incoming packet with 5 members:
{'Callerid': '102', 'State': 'Up', 'Event': 'Newstate', 'Channel': 'SIP/102-eb5f', 'Uniqueid': '1094738574.59'}

Event: Newstate
Channel: SIP/102-eb5f
State: Up
Callerid: 102
Uniqueid: 1094738574.59

<<< ------------------------<<<

>>> ------------------------>>>
Outgoing packet with 4 members:

Action: Getvar
ActionID: 1094738574.54
Variable: rep_id
Channel: SIP/102-eb5f
<<< ------------------------<<<

<<< ------------------------<<<
Incoming packet with 11 members:
{'Response': 'Success', 'AppData': '', 'Extension': 's', 'rep_id': '(null)', 'Uniqueid': '1094738574.59', 'Priority': '2', 'Application': 'Ringing', 'ActionID': '1094738574.54', 'Context': 'special', 'Event': 'Newexten', 'Channel': 'SIP/102-eb5f'}

Event: Newexten
Channel: SIP/102-eb5f
Context: special
Extension: s
Priority: 2
Application: Ringing
Uniqueid: 1094738574.59
Response: Success
rep_id: (null)
ActionID: 1094738574.54

<<< ------------------------<<<
Comments:By: Anthony Minessale (anthm) 2004-09-09 09:44:36

When you want to use a channel for 1 on 1 communication
send the Events: off header along with your Authentication

This will prevent the manager from delivering events over your socket.
what is happening is that when you send a command that requires a reply
you cannot guarentee that the next packet is for you there is also
and action id system you can use to try and sniff out your reply
from the barrage of events but you are better of to turn off events
unless you need them in which case it's better to have 2 sockets open
1 dedicated to events and the other to sending commands and getting replies.

By: dw (dw) 2004-09-09 09:49:45

Hi there, thanks for your response. This is not what is happening - I am already using ActionID to track multiple asyncronous requests to the PBX. My problem is that >an EVENT and a RESPONSE are getting MERGED in the socket stream<.

This, I assume, is due to two threads attempting to write to my socket at the same time. Please see the "additional information" above - it clearly shows data getting sent by Asterisk that violates the protocol.

I am already using the "Events" action on a seperate socket to work around this temporarily, however there still exists a bug in Asterisk. Thanks for the information on the "Events:" header!



By: Mark Spencer (markster) 2004-09-09 16:26:34

Looking at the above trace it does not appear that the answers and events are actually mixed, but it looks like you get the "Newexten" event in its entirity in between when your command and the answer.  is that a correct analysis?

By: dw (dw) 2004-09-10 04:49:02

Hi there,

Look at the last 'packet' received - it is actually two, missing an extra CRLF to seperate the "Event: Newexten" and "Response: success" for the Getvar action. The CRLF only goes missing about 1 in 5 times. Am I missing something here?


By: Mark Spencer (markster) 2004-09-10 11:09:40

Nope, I just didn't catch the real problem.  Anyway should be fixed in CVS now.  Thanks!

By: Digium Subversion (svnbot) 2008-01-15 15:07:11.000-0600

Repository: asterisk
Revision: 3759

U   trunk/apps/app_queue.c
U   trunk/channels/chan_zap.c
U   trunk/manager.c
U   trunk/res/res_features.c

r3759 | markster | 2008-01-15 15:07:11 -0600 (Tue, 15 Jan 2008) | 2 lines

Properly lock management stuff (bug ASTERISK-2373)