On Mon, May 16, 2011 at 7:55 PM, Joegen Baclor <[email protected]> wrote: > On 05/13/2011 08:37 PM, Douglas Hubler wrote: >> I think we need to decide as a project, if we want to be in the sip >> parser business. If we do, then it sounds like all the things you >> recommend and then some would need to be built. > A crash/regression test is only required if we decide to enter into the SIP > parser business? Seriously i do not get the wisdom behind this comment.
It probably would have been more clear if i wrote : *stay* in the sip parser business. >> If not, I would try >> to fix any specific issues you run into complete with unit tests for >> those fixes > We already did and patched was accepted by you personally. oh, ok, I thought you found other issues. > 1. Stay put and see if there are no more crash scenarios we have missed and > simply correct them as we encounter them. This can be a nightmare scenario > because in most cases, the bug is encountered not by QA but in actual client > live install. I reread your original post and you mention how in case #2 causes a buffer overrun. Do we know that, that isn't was caused problem #1? > 2. Review the transport layer thoroughly and see where we could put more > safeguards agaist possible buffer overruns when tokenizing sip messages. > > 3. Modify the tokenizer functions to always have the string boundary known > by its actual length so safeguards effectively becomes moot. Your post highlights the deficiencies of the test suite, and the amount of work needed to get this stack solid. I don't know the code at all, so i can only reply with what I've heard through the years about it. The sore spots of the sip stack has always been lack of features and poor performance. I didn't hear a lot about crashes, although I'm sure there were a few. Development moved very slowly, TLS was in the works for literally 8 years and maybe still not entirely there. Whatever the reason is for this, not many people would dispute these facts. Long term plan to keep a buggy or hard to maintain software is not a plan I'd recommend. I think it's really about 2 choices: put the time into the one we got or patch it along until we can replace it. You know the sip stack more than I at this point, so if you know it to be worth the effort than maybe you (or anyone) highlight it's strengths compared to other stacks so many of us can be a little more educated on this subject. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
