[asterisk-dev] Viva Chan_Sip, may it rest in peace

[Ross Beer]

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-bounces at lists.digium.com <asterisk-dev-bounces at lists.digium.com> on behalf of Olle E. Johansson <oej at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161005/5735f801/attachment.html>