[asterisk-dev] Asterisk 1.8 SIP_CAUSE performance regression

[ik]

On Thu, Aug 18, 2011 at 16:50, Bryant Zimmerman <BryantZ at zktech.com> wrote:

>  ------------------------------
> *From*: "ik" <idokan at gmail.com>
> *Sent*: Thursday, August 18, 2011 9:47 AM
> *To*: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> *Subject*: Re: [asterisk-dev] Asterisk 1.8 SIP_CAUSE performance
> regression
>
> On Thu, Aug 18, 2011 at 16:31, Matthew Nicholson <mnicholson at digium.com>wrote:
>
>> When chan_sip sets MASTER_CHANNEL(HASH(SIP_CAUSE,<chan name>)) the
>> MASTER_CHANNEL function scans the channel list which can be a slow
>> operation. Under moderate traffic loads this causes delays in processing
>> sip messages which can cause retransmission timers to expire.
>>
>> There is no other way to know the response code of a SIP message, but
>> depending on what you are using the response codes for, you may be able
>> to accomplish the same thing a different way. What are you using the
>> codes for?
>>
>
> I write application using Asterisk, and I use it to better understand the
> hangup cause, or error messages from SIP trunks.
>
>
> Ido
>
>>
>> Also be aware that this feature is not going away, it simply will be
>> disabled by default.
>>
>> On Thu, 2011-08-18 at 15:49 +0300, ik wrote:
>> > 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
>> >
>> >
>> >
>> Does it give the same data as the hangupcause when you use the h context
>> or is it different?
>>
>
Nop, hangupcause is a translation of return codes. Some SIP return codes
provide the same hangupcause code. SIP return codes contain more
information. hangupcause is more protocol agnostic.


>
>> Bryant
>>
>
Ido

>
> --
> _____________________________________________________________________
> -- 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-dev/attachments/20110818/3303fa16/attachment-0001.htm>