asterisk users - Aug 2011 - Asterisk 1.8 SIP_CAUSE performance regression

Greetings,

Recently a performance regression in chan_sip was discovered in Asterisk
1.8. The regression is caused by chan_sip setting
MASTER_CHANNEL(HASH(SIP_CAUSE,<chan name>)) after each response received
on a channel. That feature has been made optional in the latest 1.8 SVN
code, but is currently still enabled by default. After some internal
discussion, we decided to consider disabling this feature by default in
future 1.8 versions. This would be an unexpected behavior change for
anyone depending on that SIP_CAUSE update in their dialplan.
Alternatively, with this feature enabled, anyone upgrading from Asterisk
1.4 will see a 60% decrease in the amount of SIP traffic they can handle
before encountering problems.

Before disabling this feature, we wanted to get a feel for how many
people are using it. If you use this feature, please respond to this
email and let us know. 
-- 
Matthew Nicholson
Digium, Inc. | Software Developer

I'm using it.

Can you please provide more information on the issue with this feature ?
Is there another way to know the response code of SIP ?

Thanks,

Ido

On Thu, Aug 18, 2011 at 15:42, Matthew Nicholson <mnicholson at
digium.com>wrote:
> Greetings,
>
> Recently a performance regression in chan_sip was discovered in Asterisk
> 1.8. The regression is caused by chan_sip setting
> MASTER_CHANNEL(HASH(SIP_CAUSE,<chan name>)) after each response
received
> on a channel. That feature has been made optional in the latest 1.8 SVN
> code, but is currently still enabled by default. After some internal
> discussion, we decided to consider disabling this feature by default in
> future 1.8 versions. This would be an unexpected behavior change for
> anyone depending on that SIP_CAUSE update in their dialplan.
> Alternatively, with this feature enabled, anyone upgrading from Asterisk
> 1.4 will see a 60% decrease in the amount of SIP traffic they can handle
> before encountering problems.
>
> Before disabling this feature, we wanted to get a feel for how many
> people are using it. If you use this feature, please respond to this
> email and let us know.
> --
> Matthew Nicholson
> Digium, Inc. | Software Developer
>
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110818/4373e864/attachment.htm>

Hi,

We're using it here. As Ido asked, is there an alternative way of
getting the SIP response in the event a Dial() fails?

Cheers,
Kingsley.

On Thu, 2011-08-18 at 07:42 -0500, Matthew Nicholson
wrote:
> Greetings,
> 
> Recently a performance regression in chan_sip was discovered in Asterisk
> 1.8. The regression is caused by chan_sip setting
> MASTER_CHANNEL(HASH(SIP_CAUSE,<chan name>)) after each response
received
> on a channel. That feature has been made optional in the latest 1.8 SVN
> code, but is currently still enabled by default. After some internal
> discussion, we decided to consider disabling this feature by default in
> future 1.8 versions. This would be an unexpected behavior change for
> anyone depending on that SIP_CAUSE update in their dialplan.
> Alternatively, with this feature enabled, anyone upgrading from Asterisk
> 1.4 will see a 60% decrease in the amount of SIP traffic they can handle
> before encountering problems.
> 
> Before disabling this feature, we wanted to get a feel for how many
> people are using it. If you use this feature, please respond to this
> email and let us know.