> On Feb. 3, 2014, 9:41 p.m., Paul Belanger wrote: > > So, I have some comments / concerns about the 'refactor' of chan_sip. > > Basically, why are we doing it? I mean, now that chan_pjsip.c exists, I > > would very much like to see actually development of chan_sip.c stop and be > > focused on chan_pjsip. Reason being, when ever we do refactor / add new > > features to chan_sip, we end up breaking something. > > > > I know chan_pjsip is not feature par with chan_sip, however we should avoid > > reworking it when possible. > > > > Thoughts? > > Corey Farrell wrote: > chan_pjsip is brand new, I don't agree with chan_sip deprecation until > chan_pjsip has seen widespread production use for more than a year. I can > understand your concerns about changes to chan_sip, but I feel the risk can > be minimized with small changes and tests (see r3172). > > Currently 198 out of 736 unresolved bugs in JIRA are tagged with a > chan_sip component, most of those over a year old. I realize this is because > chan_sip has plenty of bugs, but they don't get addressed because chan_sip is > such a mess. I think refactoring chan_sip into isolated components will help > make it easier to troubleshoot and fix bugs.
I'm not saying we deprecate chan_sip, but more like actively avoid re factoring. This was one of the reason we decided to do chan_pjsip in the first place, chan_sip became a beast that nobody could tame. Don't get me wrong, I believe bugs should be address however at the same time, we should be actively improving chan_pjsip. So for the patch, I am happy we added a unit test, that'll help minimize regressions. - Paul ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3173/#review10745 ----------------------------------------------------------- On Feb. 3, 2014, 7:48 p.m., Corey Farrell wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3173/ > ----------------------------------------------------------- > > (Updated Feb. 3, 2014, 7:48 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-22582 > https://issues.asterisk.org/jira/browse/ASTERISK-22582 > > > Repository: Asterisk > > > Description > ------- > > Isolates code that manages struct sip_route. > > * Move route code to sip/route.c + sip/include/route.h > * Rename functions to sip_route_* > * Replace ad-hoc list code with macro's from linkedlists.h > * Create sip_route_process_header() to processes Path and Record-Route > headers (previously done with different code in build_route and build_path) > * Make sip_route uri accessor return a const > * Move struct uriparams, struct contact and contactliststruct from sip.h to > reqresp_parser.h. sip/route.c uses reqresp_parser.h but not sip.h, this was > a problem. These moved declares are not used outside of reqresp_parser. > * While modifying reqprep() the lack of {} caused me trouble. I added them. > * Code outside route.c treats sip_route as an opaque structure, using macro's > or procedures for all access. > > > Diffs > ----- > > /trunk/channels/sip/route.c PRE-CREATION > /trunk/channels/sip/include/sip.h 407178 > /trunk/channels/sip/include/route.h PRE-CREATION > /trunk/channels/sip/include/reqresp_parser.h 407178 > /trunk/channels/chan_sip.c 407178 > > Diff: https://reviewboard.asterisk.org/r/3173/diff/ > > > Testing > ------- > > > Thanks, > > Corey Farrell > >
-- _____________________________________________________________________ -- 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