Re: [asterisk-dev] One sip stack to rule them all....
On Tue, Oct 10, 2017 at 6:21 PM, James Finstrom 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 > wrote: > >> >> >> On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord 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 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 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: >h
Re: [asterisk-dev] One sip stack to rule them all....
>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. On Tue, Oct 10, 2017 at 2:40 PM, Matt Fredrickson wrote: > > > On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord 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 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 >>> 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 >> >> -- >> _
Re: [asterisk-dev] One sip stack to rule them all....
On Sun, Oct 8, 2017 at 2:00 PM, Seán C. McCord 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 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 >> 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 > 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
Re: [asterisk-dev] One sip stack to rule them all....
On 10/8/2017 10:55 AM, James Finstrom wrote: 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? FWIW, I created a tracking bug for chan_pjsip feature parity with chan_sip: https://issues.asterisk.org/jira/browse/ASTERISK-27309 If anyone feels like taking a crack at this related bugs, go for it. Kind regards, Sean -- _ -- 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
Re: [asterisk-dev] One sip stack to rule them all....
On 10/08/2017 04:47 PM, James Finstrom wrote: A large percentage of "PJSIP" Sucks comes down to comfort. I talked to several users at astricon and the summary is: Every provider that actually provides documentation only gives a chan_sip block We don't understand how to configure it. My customers need ccss. So one issue with feature parody and mostly people who simply don't want to configure it. The process of eventual removal when the ball gets rolling to do so is several releases away. PJSIP is already in use on Digium's commercial platform which shows their level of confidence in the stack. This ultimately comes down to the chicken vs the egg. Once major adoption occurs PJSIP will become a rock. PJSIP will become a rock when major adoption occurs. Looking at the tracker chan_sip has 233 open bugs, Chan_pjsip 38. So if our metric is "bugs" then there is a clear winner Remember the golden rule of software. No ticket, no bug. EASY!!! No one uses it, no tickets... no bugs! It wins! Wait... WHAT?! I most definitely do NOT want what you're smoking! Side note remember if it is removed in say Asterisk 19 (made up scenario) You don't have to use 19. All the previous releases will still have it. ...And of course none of the features or bugs fixes This is the same stuff Novell smoked. On Sun, Oct 8, 2017 at 4:51 PM, Seán C. McCord mailto:ule...@gmail.com>> wrote: I obviously failed to sufficiently emphasize the point. Whether you like it or not, whether you think pjsip is ready or not, whether it is better or not, chan_sip is effectively at a dead end. Unless some miraculously talented and motivated person emerges to maintain chan_sip (which is somewhat less likely than my dead grandmother taking up x86 assembly), there is no future for it. The discussion is not about that. There is no discussion about that. This is not about chan_sip vs chan_pjsip. It is pointless to wax about the perceived solidity of chan_sip. It is not solid. It is not maintainable. It is already years behind. People have managed to patch it into a simulacrum of stability under certain use cases (though I will admit that those use cases are wide and, in a self-fulfilling manner, perhaps do represent the majority of present use cases of active users of chan_sip), but this will not and has not continued. Factual deprecation itself is not even under discussion. chan_sip _is_ deprecated, whether that is officially acknowledged or not. Rather, this discussion is about making sure lurkers who are still using chan_sip but have not reported specific problems or feature gaps have their say, are aware that chan_sip is NOT the recommended stack, and understand that chan_sip will (again, whether anyone likes it or not) progressively worsen as time progresses. On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman mailto:brya...@zktech.com>> wrote: I would agree with this. We have tried to deploy pjsip several times over the last year with limited success. We have had nothing but issues with database real-time deployments. Tables not working from one 13.x release to another. Table builders sorcery failing out. Issues when there are multiple transports on varying networks were udp is not routed correctly through the asterisk servers. No matter the settings. Connectivity issues with varying success by carrier. Unexplained audio quality issues that don't occur on the same spec running chan_sip We want to move to pjsip but the functionality and stability have only proven out for limited applications. Bryant *From*: "Daniel Journo" mailto:d...@keshercommunications.com>> *Sent*: Sunday, October 8, 2017 3:12 PM *To*: "Asterisk Developers Mailing List" mailto:asterisk-dev@lists.digium.com>> *Subject*: Re: [asterisk-dev] One sip stack to rule them all > 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. There are a number of specific issues on issue tracker which still need addressing before more people will take it on properly. Some issues probably require a semi-major rethink and probably won’t be dealt with for months. Making chan_sip depreciated would leave Asterisk with no production grade sip stack that is officially being maintained. -- _ -- Bandwidth and Colocation
Re: [asterisk-dev] One sip stack to rule them all...
On 10/09/2017 07:11 AM, Daniel Journo wrote: Every provider that actually provides documentation only gives a chan_sip block We don't understand how to configure it. My customers need ccss. You bring up an issue that was discussed at Devcon. We, as a community, need to step up and provide this kind of documentation, best practices, and examples so people can use Asterisk (and in this case PJSIP) properly and with confidence. If we want people to use it, we need to show them how to do it in a supported and stable way. Your point about every provider only documenting chan_sip is an interesting one. Most advanced users would be able to learn how to configure PJSIP using the wiki. Beginners asking Actually the wiki SUCKS as do most wiki's... They presume too much and leave too much unsaid as "obvious". My rule of thumb when I write documents is that if I think it's obvious, it probably isn't and needs to be explicitly called out. The Asterisk book is/was good at that. I've been attempting to use the wiki for pjsip to get a recent Digium blog entry working (the one of video conferencing). It's a nice step by step... and it doesn't work for me. And precisely ZERO on how to figure out why. I WAS able to get hard phones to register, but I have to say, it's convoluted and I can't see a good reason for making it that way. Maybe it's "obvious". chan_sip has a clean configuration for endpoints. questions on the #asterisk irc channel are often told to go to the Asterisk book to learn how to configure Asterisk. As the latest Asterisk book was written for v11, I think that would be one of the major causes of the continued usage of chan_sip rather than the providers. I'm surprised to hear that Digium uses PJSIP commercially because I've always struggled with various bugs and issues. I can't reload PJSIP without causing any downtime for example. PJSIP is getting there, but it has a way to go before it can be trusted. I don't consider my use case of 100 endpoints per Asterisk box to be particularly unusual, but I do have my fair share of bugs with PJSIP. So do others I speak to on IRC. I obviously failed to sufficiently emphasize the point. Whether you like it or not, whether you think pjsip is ready or not, whether it is better or not, chan_sip is effectively at a dead end Ya know, I've seen this trumpeted quite a bit... A dead end is something going nowhere and doesn't work. Like it or NOT... It seems that for a significant number of applications chan_sip DOES work and does so better than pjsip does. As I was taught many, many, years ago, good engineering is about cost effective solutions, not "whiz bang" technology. If the cost in effort/downtime/etc is more for the "cool/forward looking" technology is higher and presents barriers to adoption, that test fails. I'm not sure what the purpose of this thread is then. It seems like this is not actually a question of whether it should be depreciated. Just a statement that it is. If it is, PJSIP needs some serious work otherwise it opens the window for commercial solutions to take some market share. If chan_sip is a dead end and it is made officially depreciated, it would have the following effect:- - It would 'hopefully' increase uptake and therefore bug reports. As long as there are people able to work through them, that’s fine. Otherwise, it opens the window for commercial solutions to take some market share. - There would currently be no reliable sip stack for some use cases whereas chan_sip worked fine as some support is still available. -- _ -- 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
Re: [asterisk-dev] One sip stack to rule them all...
>> Every provider that actually provides documentation only gives a chan_sip >> block >> We don't understand how to configure it. >> My customers need ccss. > You bring up an issue that was discussed at Devcon. We, as a community, need > to step up and provide this kind of documentation, best practices, and > examples so people can use Asterisk (and in this case PJSIP) properly and > with confidence. > If we want people to use it, we need to show them how to do it in a supported > and stable way. Your point about every provider only documenting chan_sip is an interesting one. Most advanced users would be able to learn how to configure PJSIP using the wiki. Beginners asking questions on the #asterisk irc channel are often told to go to the Asterisk book to learn how to configure Asterisk. As the latest Asterisk book was written for v11, I think that would be one of the major causes of the continued usage of chan_sip rather than the providers. I'm surprised to hear that Digium uses PJSIP commercially because I've always struggled with various bugs and issues. I can't reload PJSIP without causing any downtime for example. PJSIP is getting there, but it has a way to go before it can be trusted. I don't consider my use case of 100 endpoints per Asterisk box to be particularly unusual, but I do have my fair share of bugs with PJSIP. So do others I speak to on IRC. >>> I obviously failed to sufficiently emphasize the point. Whether you like >>> it or not, whether you think pjsip is ready or not, whether it is better or >>> not, chan_sip is effectively at a dead end I'm not sure what the purpose of this thread is then. It seems like this is not actually a question of whether it should be depreciated. Just a statement that it is. If it is, PJSIP needs some serious work otherwise it opens the window for commercial solutions to take some market share. If chan_sip is a dead end and it is made officially depreciated, it would have the following effect:- - It would 'hopefully' increase uptake and therefore bug reports. As long as there are people able to work through them, that’s fine. Otherwise, it opens the window for commercial solutions to take some market share. - There would currently be no reliable sip stack for some use cases whereas chan_sip worked fine as some support is still available. -- _ -- 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
[asterisk-dev] One sip stack to rule them all...
> > Date: Sun, 8 Oct 2017 19:47:32 -0400 > From: James Finstrom > To: Asterisk Developers Mailing List > Subject: Re: [asterisk-dev] One sip stack to rule them all > > A large percentage of "PJSIP" Sucks comes down to comfort. I talked to > several users at astricon and the summary is: > > Every provider that actually provides documentation only gives a chan_sip > block > We don't understand how to configure it. > My customers need ccss. > James, You bring up an issue that was discussed at Devcon. We, as a community, need to step up and provide this kind of documentation, best practices, and examples so people can use Asterisk (and in this case PJSIP) properly and with confidence. If we want people to use it, we need to show them how to do it in a supported and stable way. Eric Klein VP Operations Greenfield Main US +1 805 410 1010 Main UK +44 203 746 6000 Main Il+972 73 255 7799 Mobile+972 54 666 0933 *Email *e...@greenfield.tech Skype: EricLKlein Web: www.greenfield.tech www.cloudonix.io -- _ -- 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
Re: [asterisk-dev] One sip stack to rule them all....
Correction on number of bugs, most PJSIP bugs are filed against resource modules. If you select all of the "Resources/res_pj*" categories in addition to Channels/chan_pjsip it shows 121 open bugs. People are reporting issues against the pjsip modules, most are not against the channel driver itself. On 10/08/2017 07:47 PM, James Finstrom wrote: A large percentage of "PJSIP" Sucks comes down to comfort. I talked to several users at astricon and the summary is: Every provider that actually provides documentation only gives a chan_sip block We don't understand how to configure it. My customers need ccss. So one issue with feature parody and mostly people who simply don't want to configure it. The process of eventual removal when the ball gets rolling to do so is several releases away. PJSIP is already in use on Digium's commercial platform which shows their level of confidence in the stack. This ultimately comes down to the chicken vs the egg. Once major adoption occurs PJSIP will become a rock. PJSIP will become a rock when major adoption occurs. Looking at the tracker chan_sip has 233 open bugs, Chan_pjsip 38. So if our metric is "bugs" then there is a clear winner Remember the golden rule of software. No ticket, no bug. Side note remember if it is removed in say Asterisk 19 (made up scenario) You don't have to use 19. All the previous releases will still have it. On Sun, Oct 8, 2017 at 4:51 PM, Seán C. McCord <mailto:ule...@gmail.com>> wrote: I obviously failed to sufficiently emphasize the point. Whether you like it or not, whether you think pjsip is ready or not, whether it is better or not, chan_sip is effectively at a dead end. Unless some miraculously talented and motivated person emerges to maintain chan_sip (which is somewhat less likely than my dead grandmother taking up x86 assembly), there is no future for it. The discussion is not about that. There is no discussion about that. This is not about chan_sip vs chan_pjsip. It is pointless to wax about the perceived solidity of chan_sip. It is not solid. It is not maintainable. It is already years behind. People have managed to patch it into a simulacrum of stability under certain use cases (though I will admit that those use cases are wide and, in a self-fulfilling manner, perhaps do represent the majority of present use cases of active users of chan_sip), but this will not and has not continued. Factual deprecation itself is not even under discussion. chan_sip _is_ deprecated, whether that is officially acknowledged or not. Rather, this discussion is about making sure lurkers who are still using chan_sip but have not reported specific problems or feature gaps have their say, are aware that chan_sip is NOT the recommended stack, and understand that chan_sip will (again, whether anyone likes it or not) progressively worsen as time progresses. On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman mailto:brya...@zktech.com>> wrote: I would agree with this. We have tried to deploy pjsip several times over the last year with limited success. We have had nothing but issues with database real-time deployments. Tables not working from one 13.x release to another. Table builders sorcery failing out. Issues when there are multiple transports on varying networks were udp is not routed correctly through the asterisk servers. No matter the settings. Connectivity issues with varying success by carrier. Unexplained audio quality issues that don't occur on the same spec running chan_sip We want to move to pjsip but the functionality and stability have only proven out for limited applications. Bryant *From*: "Daniel Journo" mailto:d...@keshercommunications.com>> *Sent*: Sunday, October 8, 2017 3:12 PM *To*: "Asterisk Developers Mailing List" mailto:asterisk-dev@lists.digium.com>> *Subject*: Re: [asterisk-dev] One sip stack to rule them all > 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. There are a number of specific issues on issue tracker which still need addressing before more people will take it on properly. Some issues probably require a semi-major rethink and probably won’t be dealt with for months. Making chan_sip d
Re: [asterisk-dev] One sip stack to rule them all....
A large percentage of "PJSIP" Sucks comes down to comfort. I talked to several users at astricon and the summary is: Every provider that actually provides documentation only gives a chan_sip block We don't understand how to configure it. My customers need ccss. So one issue with feature parody and mostly people who simply don't want to configure it. The process of eventual removal when the ball gets rolling to do so is several releases away. PJSIP is already in use on Digium's commercial platform which shows their level of confidence in the stack. This ultimately comes down to the chicken vs the egg. Once major adoption occurs PJSIP will become a rock. PJSIP will become a rock when major adoption occurs. Looking at the tracker chan_sip has 233 open bugs, Chan_pjsip 38. So if our metric is "bugs" then there is a clear winner Remember the golden rule of software. No ticket, no bug. Side note remember if it is removed in say Asterisk 19 (made up scenario) You don't have to use 19. All the previous releases will still have it. On Sun, Oct 8, 2017 at 4:51 PM, Seán C. McCord wrote: > I obviously failed to sufficiently emphasize the point. Whether you like > it or not, whether you think pjsip is ready or not, whether it is better or > not, chan_sip is effectively at a dead end.Unless some miraculously > talented and motivated person emerges to maintain chan_sip (which is > somewhat less likely than my dead grandmother taking up x86 assembly), > there is no future for it. The discussion is not about that. There is no > discussion about that. This is not about chan_sip vs chan_pjsip. It is > pointless to wax about the perceived solidity of chan_sip. It is not > solid. It is not maintainable. It is already years behind. People have > managed to patch it into a simulacrum of stability under certain use cases > (though I will admit that those use cases are wide and, in a > self-fulfilling manner, perhaps do represent the majority of present use > cases of active users of chan_sip), but this will not and has not continued. > > Factual deprecation itself is not even under discussion. chan_sip _is_ > deprecated, whether that is officially acknowledged or not. > > Rather, this discussion is about making sure lurkers who are still using > chan_sip but have not reported specific problems or feature gaps have their > say, are aware that chan_sip is NOT the recommended stack, and understand > that chan_sip will (again, whether anyone likes it or not) progressively > worsen as time progresses. > > > On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman > wrote: > >> I would agree with this. We have tried to deploy pjsip several times over >> the last year with limited success. >> We have had nothing but issues with database real-time deployments. >> Tables not working from one 13.x release to another. >> Table builders sorcery failing out. >> >> Issues when there are multiple transports on varying networks were udp is >> not routed correctly through the asterisk servers. No matter the settings. >> >> Connectivity issues with varying success by carrier. >> >> Unexplained audio quality issues that don't occur on the same spec >> running chan_sip >> >> We want to move to pjsip but the functionality and stability have only >> proven out for limited applications. >> >> >> Bryant >> >> -- >> *From*: "Daniel Journo" >> *Sent*: Sunday, October 8, 2017 3:12 PM >> *To*: "Asterisk Developers Mailing List" >> *Subject*: Re: [asterisk-dev] One sip stack to rule them all >> >> >> > 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. >> >> There are a number of specific issues on issue tracker which still need >> addressing before more people will take it on properly. Some issues >> probably require a semi-major rethink and probably won’t be dealt with for >> months. >> Making chan_sip depreciated would leave Asterisk with no production grade >> sip stack that is officially being maintained. >> -- >> _ >> -- 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/G
Re: [asterisk-dev] One sip stack to rule them all....
I obviously failed to sufficiently emphasize the point. Whether you like it or not, whether you think pjsip is ready or not, whether it is better or not, chan_sip is effectively at a dead end.Unless some miraculously talented and motivated person emerges to maintain chan_sip (which is somewhat less likely than my dead grandmother taking up x86 assembly), there is no future for it. The discussion is not about that. There is no discussion about that. This is not about chan_sip vs chan_pjsip. It is pointless to wax about the perceived solidity of chan_sip. It is not solid. It is not maintainable. It is already years behind. People have managed to patch it into a simulacrum of stability under certain use cases (though I will admit that those use cases are wide and, in a self-fulfilling manner, perhaps do represent the majority of present use cases of active users of chan_sip), but this will not and has not continued. Factual deprecation itself is not even under discussion. chan_sip _is_ deprecated, whether that is officially acknowledged or not. Rather, this discussion is about making sure lurkers who are still using chan_sip but have not reported specific problems or feature gaps have their say, are aware that chan_sip is NOT the recommended stack, and understand that chan_sip will (again, whether anyone likes it or not) progressively worsen as time progresses. On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman wrote: > I would agree with this. We have tried to deploy pjsip several times over > the last year with limited success. > We have had nothing but issues with database real-time deployments. Tables > not working from one 13.x release to another. > Table builders sorcery failing out. > > Issues when there are multiple transports on varying networks were udp is > not routed correctly through the asterisk servers. No matter the settings. > > Connectivity issues with varying success by carrier. > > Unexplained audio quality issues that don't occur on the same spec running > chan_sip > > We want to move to pjsip but the functionality and stability have only > proven out for limited applications. > > > Bryant > > -- > *From*: "Daniel Journo" > *Sent*: Sunday, October 8, 2017 3:12 PM > *To*: "Asterisk Developers Mailing List" > *Subject*: Re: [asterisk-dev] One sip stack to rule them all > > > > 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. > > There are a number of specific issues on issue tracker which still need > addressing before more people will take it on properly. Some issues > probably require a semi-major rethink and probably won’t be dealt with for > months. > Making chan_sip depreciated would leave Asterisk with no production grade > sip stack that is officially being maintained. > -- > _ > -- 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 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
Re: [asterisk-dev] One sip stack to rule them all....
I would agree with this. We have tried to deploy pjsip several times over the last year with limited success. We have had nothing but issues with database real-time deployments. Tables not working from one 13.x release to another. Table builders sorcery failing out. Issues when there are multiple transports on varying networks were udp is not routed correctly through the asterisk servers. No matter the settings. Connectivity issues with varying success by carrier. Unexplained audio quality issues that don't occur on the same spec running chan_sip We want to move to pjsip but the functionality and stability have only proven out for limited applications. Bryant From: "Daniel Journo" Sent: Sunday, October 8, 2017 3:12 PM To: "Asterisk Developers Mailing List" Subject: Re: [asterisk-dev] One sip stack to rule them all > 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. There are a number of specific issues on issue tracker which still need addressing before more people will take it on properly. Some issues probably require a semi-major rethink and probably won't be dealt with for months. Making chan_sip depreciated would leave Asterisk with no production grade sip stack that is officially being maintained. -- _ -- 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
Re: [asterisk-dev] One sip stack to rule them all....
> 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. There are a number of specific issues on issue tracker which still need addressing before more people will take it on properly. Some issues probably require a semi-major rethink and probably won’t be dealt with for months. Making chan_sip depreciated would leave Asterisk with no production grade sip stack that is officially being maintained. -- _ -- 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
Re: [asterisk-dev] One sip stack to rule them all....
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. On Sun, Oct 8, 2017 at 12:56 PM Troy Bowman 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 > 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 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
Re: [asterisk-dev] One sip stack to rule them all....
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 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
Re: [asterisk-dev] One sip stack to rule them all....
The Real-Time Text feature of Asterisk does not work with PJSIP. Or at least it is not documented how its redundant transport support is configured. See: https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4260034 for how it once worked. (There are bugs in the release 11 and 13 implementations of redundant transmission of real-time text with chan_sip as well, but it worked in earlier releases. ) Den 2017-10-08 kl. 16:55, skrev James Finstrom: 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
Re: [asterisk-dev] One sip stack to rule them all....
Having run pjsip for about a year now in production, I can say that the current implementation isn’t very reliable for scaling. Due to the issues I describe below, I have to run multiple asterisk boxes with around 100 endpoints per box max. Even at that leve, Asterisk on all boxes randomly stop responding to sip packets for up to 30 seconds. It only happens 2 to 3 times a week which makes debugging or running core dumps hard to catch. It does however still send out OPTIONS so it’s not totally dead during that time. The CLI still works as normal too. I had a discussion with George about this, but we never found a solution due to the difficulty in capturing a core dump of the issue. Another problem is Qualify. When doing PJSIP RELOAD, Asterisk stops dealing with inbound packets for about 60 seconds (while it qualifies everything again?). Asterisk start up time is also greatly increased by qualify in PJSIP. My short term plan is to switch back to Chansip until the issues are resolved. A discussion relating to depreciating chansip is a little worrying for me at this time. Here are some issues related to this that I’ve been monitoring. I have tried to dive into the code, but it’s too steeper learning curve for me to work out how things are being done. https://issues.asterisk.org/jira/browse/ASTERISK-27247 https://issues.asterisk.org/jira/browse/ASTERISK-26806 https://issues.asterisk.org/jira/browse/ASTERISK-26599 https://issues.asterisk.org/jira/browse/ASTERISK-26194 From: asterisk-dev-boun...@lists.digium.com [mailto:asterisk-dev-boun...@lists.digium.com] On Behalf Of James Finstrom Sent: 08 October 2017 15:56 To: Asterisk Developers Mailing List Subject: [asterisk-dev] One sip stack to rule them all 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
[asterisk-dev] One sip stack to rule them all....
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