On Tue, Oct 10, 2017 at 6:21 PM, James Finstrom <jfinst...@gmail.com> wrote:
> From my original email: > > """ > So one of the things that is needed to finally put Chan sip to bed is > feature parody. Someone brought up CCSS. > What features do you feel you would lose going from chan_sip to pjsip. > Are there any bugs in pjsip that keep you from migrating? > """ > > To clear up the tl;dr was what needs to happen to get you to convert. > > The goal of this was to find the path that gets us to the goal of wide > spread adoption of pjsip. Pjsip seems to get a lot of criticism but most > of it is not constructive. There needs to be constructive feed back that > is better thought out than "it sucks" or "it is buggy". > > What is it YOU are missing to transition? > > Documentation? Is there something not covered? > > https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip > https://wiki.asterisk.org/wiki/display/AST/Migrating+ > from+chan_sip+to+res_pjsip > > Bugs? > Sean did https://issues.asterisk.org/jira/browse/ASTERISK-27309 > Is there any specific open bugs of concern? > Do you have a reproducible unreported bug? > Do you have a feature in chan_sip that doesn't exist in pjsip that is not > in sean's ticket? > > Help the developers help you. Documentation was mentioned at devcon and in > this post. > Again if there is something NOT on the wiki, or something that needs to be > stripped down to simpler terms bring it up so someone can write it. > Thanks for clarifying, James. This type of data is useful and helpful in trying to continue to improve chan_pjsip. As far as contingent actions (such as marking chan_sip as deprecated) my opinion is that they are still premature - as mentioned in my other reply. Best wishes, Matthew Fredrickson > > On Tue, Oct 10, 2017 at 2:40 PM, Matt Fredrickson <cres...@digium.com> > wrote: > >> >> >> On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord <ule...@gmail.com> wrote: >> >>> As James mentioned at the top, chan_sip is already de facto deprecated. >>> The discussion (at devcon) was centered around making it _officially_ >>> deprecated. >>> >>> For clarity, deprecation is NOT the same thing as removal. (It is also >>> not depreciation, the reduction in value of something.) Deprecation is the >>> declaration that something is not approved. Using chan_sip has not been >>> recommended for a long time. >>> >>> It _is_ important to officially deprecate chan_sip because it is really >>> isn't being maintained as it would otherwise need to be. There is no >>> reasonable way _to_ maintain it. Users should _know_ of that status, and >>> that status is highly unlikely to change. >>> >> >>> What is _also_ needed, however, is more use of PJSIP and reports of >>> specific problems, and specific deficits of PJSIP so that the fear can be >>> eased before, at some point many years from now, chan_sip just doesn't work >>> any more. >>> >> >> I think it's probably premature to conclude that marking chan_sip >> deprecation is the right answer at this time. I would argue that there are >> many more modules in Asterisk's code base that have less maintenance than >> chan_sip but are still permitted to be there. >> >> I do think that the exercise of finding problematic scenarios and missing >> features is useful right now, as it allows us to continue to improve >> chan_pjsip and see if there are problematic scenarios or missing critical >> features. But my point of view is what I have already said - it is >> premature to mark it as deprecated. >> >> Matthew Fredrickson >> >> >>> >> >>> >>> On Sun, Oct 8, 2017 at 12:56 PM Troy Bowman <t...@lump.net> wrote: >>> >>>> I sincerely hope they don't deprecate it. The pjsip code might seem >>>> fine in development and test environments, but I am still afraid of using >>>> it in production. I see too many issues with it regularly on this list. I >>>> can't gamble stability versus my job security. >>>> >>>> From my perspective, chan_sip doesn't get bugfixes because it doesn't >>>> seem to need them. It just works. I have had zero issues with it for >>>> several years. >>>> >>>> >>>> On Sun, Oct 8, 2017 at 8:55 AM, James Finstrom <jfinst...@gmail.com> >>>> wrote: >>>> >>>>> One does not simply depricate a sip stack. >>>>> >>>>> Ok so at devcon there was a discussion of depricating chan_sip. This >>>>> may sound a lot worse than it actually is. Chan_sip has been essentially >>>>> untouched in 4ish years. It does not receive bug fixes. It is just sort of >>>>> a barge floating in the ocean. >>>>> >>>>> So one of the things that is needed to finally put Chan sip to bed is >>>>> feature parody. Someone brought up CCSS. >>>>> >>>>> What features do you feel you would lose going from chan_sip to pjsip. >>>>> >>>>> Are there any bugs in pjsip that keep you from migrating? >>>>> >>>>> -- >>>>> _____________________________________________________________________ >>>>> -- 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 >>>>> >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- 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 >>> >>> -- >>> Seán C McCord >>> CyCore Systems, Inc >>> +1 888 240 0308 <(888)%20240-0308> >>> PGP/GPG: http://cycoresys.com/scm.asc >>> >>> -- >>> _____________________________________________________________________ >>> -- 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 >>> >> >> >> >> -- >> Matthew Fredrickson >> Digium, Inc. | Engineering Manager >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> >> -- >> _____________________________________________________________________ >> -- 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 >> > > > > -- > James > > -- > _____________________________________________________________________ > -- 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 > -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
-- _____________________________________________________________________ -- 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