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:* [email protected]
<[email protected]> on behalf of Olle E. Johansson
<[email protected]>
*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>
--
_____________________________________________________________________
-- 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
