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

[Dmitriy Serov]

I have done exactly the same way from chan_sip to res_pjsip. It was a 
great stress!

I talked a lot with Joshua Colp. Big thanks to him for the help.
But even now in the res_pjsip much of the functionality is unavailable. 
I wrote a mail to the mailing lists, created issues.
Much of the requested is not implemented and it is not changing.

Moreover, I couldn't go with 13.9 for newer versions. The reason for 
this is unexplained fall immediately after loading in several different 
places.
Perhaps it's the personal features of my "old" operating system 
(slackware).

I will be very happy if there is such a purpose, and a working group 
that will implement it.

05.10.2016 13:14, 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 
> <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 
> <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/fb03ab42/attachment-0001.html>