[asterisk-bugs] [Asterisk 0009055]: [patch] extend SMDI support to chan_sip

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=9055 
====================================================================== 
Reported By:                jaroth
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   9055
Category:                   Core/General
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     resolved
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 54176 
Disclaimer on File?:        Yes 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             02-13-2007 14:07 CST
Last Modified:              12-12-2007 10:27 CST
====================================================================== 
Summary:                    [patch] extend SMDI support to chan_sip
Description: 
This patch allows SMDI message integration with SIP.  Currently only Zap
channels can utilize SMDI messaging.  If all VoIP signalling to Asterisk is
done via SIP, there is currently no support for SMDI.  Since SIP signalling
packets can not be guaranteed to arrive in the same order as SMDI messages,
a new method was added to the smdi module to allow matching of the SIP
INVITE source (ex. 0001 at 192.168.1.10) to the message desk terminal number
(ex. 0001, 0002, etc)

This patch also allows each voicemail user to specify if they will be
using SMDI for MWI notification, instead of having extern_notify set to
SMDI.  There are instances when some users will need SMDI notification and
others will want to use the built-in MWI support.
====================================================================== 

---------------------------------------------------------------------- 
 russell - 12-12-07 10:27  
---------------------------------------------------------------------- 
I have decided to take on this project with an alternate implementation. 
However, let me point out some of the more serious problems that we
discovered in this patch.

The chunk of code that does most of the work in this patch in chan_sip is
done in the part of the code that processes incoming INVITES.  When working
on chan_sip, it is critical to recognize that chan_sip uses a single thread
for processing incoming messages.  Because of this, you can not introduce
code that blocks for any appreciable amount of time.

In this case, the code may block for up to a second and a half in some
situations.  During that time, no other SIP calls can get processed. 
Furthermore, the way that the ast_smdi_md_message_wait_for_callid()
function was implemented is very problematic for a couple of different
reasons.

The first problem with this function is that it implements a busy loop. 
That means that as long as this function is running, it will eat up as much
CPU time as it possibly can.  This would certainly affect the quality of
any active calls on the system.

The second big problem with the use of this function is memory management.
 This function returns an SMDI message to get processed in chan_sip, but
never gets destroyed.  The memory allocated for every SMDI message is being
leaked. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-12-07 10:27  russell        Status                   feedback => resolved
12-12-07 10:27  russell        Resolution               open => fixed       
12-12-07 10:27  russell        Assigned To               => russell         
12-12-07 10:27  russell        Note Added: 0075272                          
======================================================================