Impossible To Use Any Recent Asterisk Version With Chan_sip

Home » Asterisk Users » Impossible To Use Any Recent Asterisk Version With Chan_sip
Asterisk Users 8 Comments

Hello, I’d like to know if anyone of you is finding my same problems using any recent asterisk version, after 13.7 / 13.8 with chan_sip.

If I use any recent asterisk version, after just few seconds asterisk completely locks up, stopping processing SIP/UDP packets. Nothing is written in the asterisk log, but if I run “netstat -nap | grep 5060” I see the UDP buffer filled up.

If I step back to asterisk 13.2, then all is fine and asterisk is rock solid.

I know I should use PJSIP and chan_sip is no more supported, but at this point, if this is the working state of chan_sip, it should be completely removed.

Leandro

8 thoughts on - Impossible To Use Any Recent Asterisk Version With Chan_sip

  • Leandro Dardini wrote:

    It’s not the normal working state of chan_sip, in fact it hasn’t really been touched in any way that would cause this to happen and I haven’t seen any bug reports along these lines. I also know that FreePBX is running both chan_sip and chan_pjsip and haven’t experienced anything so it may be isolated to you. If you follow the instructions on the wiki[1]
    it will provide a backtrace which will show where chan_sip is hanging.

    [1]
    https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock

  • Barry Flanagan wrote:

    Ah, that slipped my memory! Only the single person reporting it thus far. If another backtrace can be added we can see if it’s the same thing.

  • Leandro Dardini wrote:

    I’ve responded on the issue but the backtrace you’ve provided makes it appear as though the issue is actually in ODBC, which since chan_sip is using it in your deployment it causes it to lock up (why exactly is unknown).

    Since it’s separate you should create a new issue. If you don’t want to I can do so tomorrow. The complete console output (with debug going to console in logger.conf and core set debug 3) as well as the configuration would also be useful.

    Cheers,

  • Leandro Dardini wrote:

    Nothing else is needed from you! All the information has shown it’s actually func_odbc. It’s not using res_odbc like it should be, which causes issues as a result of a fixup from some multi-connection problems. We’ll get it sorted.

  • Leandro Dardini wrote:

    And thank you for testing the release candidate so we can ensure the issue is fixed before doing the actual release!

  • No. I thank you for all the hard work done and dedication to the project.

    Leandro Il 06/Lug/2016 11:10 PM, “Joshua Colp” ha scritto: