[Home]

Summary:ASTERISK-16242: MSG_OOB flag on HANGUP packet misused
Reporter:Bryce Baril (brycebaril)Labels:
Date Opened:2010-06-14 15:51:00Date Closed:2010-06-16 13:50:11
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_agi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When using fast AGI and the AGISIGHUP flag is enabled, Asterisk sends an Out-of-Band "HANGUP\n" packet when the channel is terminated.  It uses the MSG_OOB flag to send it URG/Out-of-Band via TCP.

This TCP feature is generally not used and not reliable (e.g. http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Out_of_band_data ) and in this case will cause only the "\n" character to be sent OOB.  The "HANGUP" is still sent in-band, and can cause buffering issues -- especially with the "\n" being sent in a different band.  

Even if the developer sets socket options to get the OOB data in-band, the "\n" will come in prior to the "HANGUP" because it is a higher priority.

I suggest dropping the "MSG_OOB" flag from this packet, as it doesn't seem to do any good, and possibly only does harm.
Comments:By: Paul Belanger (pabelanger) 2010-06-14 17:28:29

Are you able to provide a patch?
By: Tilghman Lesher (tilghman) 2010-06-15 09:51:57

Actually, the MSG_OOB is a misnomer, because messages aren't actually sent out of band; the urgent flag is set and the urgent pointer is set to the last byte of the message (which is why you see the '\n').  Both the "HANGUP" and the "\n" are sent in band, both at the same time, and they cannot occur outside of the protocol, other than to say that the "HANGUP\n" will be received by the AGI at a time when it normally would be writing a command.

In fact, what you should be doing in your FastAGI is setting a handler for the SIGURG signal, which is normally ignored, so you can receive a notification when the urgent packet arrives (but arrives in band).
By: Bryce Baril (brycebaril) 2010-06-15 11:04:10

This is not my observation.

When I read the data off the socket I see exactly 6 bytes, and they are "HANGUP"

If I alter my socket like so:
setsockopt($agi_socket, SOL_SOCKET, SO_OOBINLINE, 1);

I receive a new message on the socket, 1 byte: "\n"

The next message on the socket is: 6 bytes "HANGUP"

So far I have been unable to get SIGURG to be triggered by this message.
By: Tilghman Lesher (tilghman) 2010-06-15 13:12:31

What language are you using?
By: Bryce Baril (brycebaril) 2010-06-15 15:57:19

I am using Perl, which doesn't have any wrappers over setsockopt, or anything else related to this protocol.  What I'm seeing matches the TCP documentation I've found.

Its safe signal handling may be interfering with SIGURG, but that isn't the ideal solution for my application.
By: Digium Subversion (svnbot) 2010-06-16 13:43:22

Repository: asterisk
Revision: 270936

U   trunk/CHANGES
U   trunk/res/res_agi.c

------------------------------------------------------------------------
r270936 | pabelanger | 2010-06-16 13:43:22 -0500 (Wed, 16 Jun 2010) | 8 lines

MSG_OOB flag on HANGUP packet removed.

Per Tilghman's request on IRC (#asterisk-bugs).

(closes issue ASTERISK-16242)
Reported by: brycebaril
Tested by: pabelanger, tilghman

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=270936
By: Digium Subversion (svnbot) 2010-06-16 13:50:10

Repository: asterisk
Revision: 270937

_U  branches/1.6.2/
U   branches/1.6.2/CHANGES
U   branches/1.6.2/res/res_agi.c

------------------------------------------------------------------------
r270937 | pabelanger | 2010-06-16 13:50:10 -0500 (Wed, 16 Jun 2010) | 15 lines

Merged revisions 270936 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r270936 | pabelanger | 2010-06-16 14:43:22 -0400 (Wed, 16 Jun 2010) | 8 lines
 
 MSG_OOB flag on HANGUP packet removed.
 
 Per Tilghman's request on IRC (#asterisk-bugs).
 
 (closes issue ASTERISK-16242)
 Reported by: brycebaril
 Tested by: pabelanger, tilghman
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=270937