Hi
I have spent over a year migrating from chan_sip (1.8) to chan_pjsip (13) and it has been stressful. However, there is light at the end of the tunnel. When first migrating Asterisk would crash around 20 times a day or more. However, by investing time and money into resolving the segfaults, database issues and task managers I feel that the new stack is stable with the odd bug still remaining. The most common crash I get from the stack at the moment is due to TLS connections, which the PJSIP team are currently working on and I am assured there will be a patch in the coming days. >From experience, I can say that chan_pjsip is more scalable and efficiently >uses server resources compared to chan_sip. It is the way forward! I would welcome a working group to manage the migration from chan_sip to chan_pjsip as there are still features in chan_sip that have not been implemented in chan_pjsip. I would also welcome additional features such as 'Device Feature Key Synchronization' (as-feature-event). At present, there are a few undocumented features, such as the sorcery configuration: endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error The above stops a full database query that loads every single endpoint at startup, which can cause overload on systems with a number of endpoints. Therefore documentation covering the whole sip stack and features would help people migrate easier. Finally, I would like to thank everyone who has been working on ironing out the chan_pjsip bugs. Ross ________________________________ From: asterisk-dev-boun...@lists.digium.com <asterisk-dev-boun...@lists.digium.com> on behalf of Olle E. Johansson <o...@edvina.net> Sent: 05 October 2016 10:42 To: Asterisk Developers Mailing List Cc: Olle E Johansson Subject: Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace Hi! >From my perspective I know that maintaining a SIP stack requires *A LOT* of >effort, so I understand that a project can't maintain two of them. I suggest that a working group is created for the transition and that the first task is to compare the functionality. Last time I checked the functionality *I need* (but maybe not everyone else) was non-existing in PJSIP so I could not use it. It may have changed since then. I think the goal has to be to gradually phase out the ugly code in chan_sip and celebrate the day it's gone, but make sure we don't leave functionality (and users) behind and have good guidelines for the transition. I still think we should totally rewrite how chan_pjsip is configured. That concept is very far away from other SIP implementations. But that's my personal opinion from a small cold corner of the world, using Asterisk in non-PBX ways as large scale media and feature servers. Executive summary: Create a working group that maintains the feature gap, makes sure it's going away and also makes sure that we have enough material that explains the gold that hides in chan_pjsip! /O -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- api digital - problem solved.<http://www.api-digital.com/> www.api-digital.com API Digital Website asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
-- _____________________________________________________________________ -- 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