Re: [reSIProcate] Open issues remaining for 1.1 release

[Byron Campen <bcampen@xxxxxxxxxxxx>]

It looks like we are just about ready to drop a release candidate. What remains is generating the release notes. I ask everyone who has made significant contributions please send a summary of what you've done. Here's the current state of open issues:

New issues with some work remaining:

1. Dealing with quoted qop (see [reSIProcate] qop Parameter Parsing) (code in branch, will merge into main, but this will have to wait for 1.2)

3. Problem with SharedPtr on Solaris ( see [reSIProcate] Bugs in SharedPtr and SharedCount of ReSip1.0 when using libCstd compiling(not libstlport4) on SOLARIS ) (unknown, probably standards-compliance issue in libCstd)

6. API problem in SipStack::addTransport() (see [reSIProcate] Creating a DUM with automatic port? ) (offending default port removed, might be nice to have the ability to tell the stack to open a transport on an ephemeral port)

10. Possible heap corruption on deletion of SipStack ( see [reSIProcate] Crash in ares on deleting SipStack ) (following up on list, probably a link error)

16. Update license blocks. (see [reSIProcate] Copyrights)

22. Seg fault in resip/dum/test/BasicCall.cxx test-case (see [reSIProcate] Issue calling end() in onNewSession) (unresolved)

23. Potential problem with rutil/SharedPtr (see [reSIProcate] rutil SharedPtr use) (unknown)

For issue 1, we have code, but I think the best course of action is to merge into main, and defer its release to 1.2. 

For issue 3, I have been unable to find any evidence that we're doing anything wrong. I think this should be considered resolved.

For issue 6, the remaining work might be something that would be useful, but I haven't gotten much of a sense of urgency.

For issue 10, this looks like the result of linking against two versions of malloc. Nobody seems to be having the same problem.

For issue 16, I am still unclear on what (if anything) should be done. Could someone who knows this stuff please speak up?

For issue 22, no patch has been applied, but it is just a test-case.

For issue 23, I have no idea what might be going on here. Has anyone ever seen this happen? In any case, we shouldn't hold the release up on this. If we do actually find a problem, we can backport the fix.

Solved:

5. Empty contents problem in client publish code in DUM ( see [reSIProcate] [PATCH] Empty PUBLISH body if there is a pending publish ) (resolved)

7. V6 address storage problem in Tuple (see [reSIProcate] IPv6 address in Via header gets its lower order bits chopped off (Win32 platform)) (resolved)

8. Possible problem in SdpContents::getBodyData() ( see [reSIProcate] SdpContents::getBodyData() returns stack pointer ) (resolved, third-party problem)

9. install target issues with dum and stack ( see [reSIProcate] Minor Makefile issues ) (resolved)

12. Possible failure in DUM unit test ( see [reSIProcate] DUM test fails ) (resolved)

13. Problem with merged-request detection in DUM (see [reSIProcate] Call routed back to reSIProcate by SipX PBX after 302 temp moved .) (resolved)

14. Shared library build broken on x86_64 ( see [reSIProcate] building shared libraries on AMD64) (resolved)

15. Problems with unsolicited NOTIFY in DUM ( see [reSIProcate] refer with refSub = false stillcauseClientSubscriptionHandler be used ) (resolved)

17. configure script error on Ubuntu ( see Re: [reSIProcate] Open issues for 1.1 release) (resolved)

18. repro/debian/patches, does this still belong here?( see Re: [reSIProcate] Open issues for 1.1 release)

19. Symlinks to binaries are no longer created. (resolved)

20. Build is hosed on OS X (resolved)

21. The "u=" is not encoded before the Uri of description in SdpContents::Session::encode() (see [reSIProcate] Bug in SdpContents encode method) (resolved)

Old open issues:

A.  URI parsing bug in XMLCursor???

B.  Not using PrivateKey pass phrases at all.  All private keys must be

unencrypted on the disk.

C.  Change to DateCategory to make is more compatible with other

implementations.  (we should probably go ahead and do this)

D. Parser validation issues from Kayote. (Contact * can be allowed in

any Nameaddr)

E. PIDF XML parsing support for XML namespaces - The patch was not

applied, not addressed. Derek says we may want to deprecate our XML

parsing stuff; this will end up making A moot as well. (If the decision is to deprecate, lets go ahead and do it already.)

F. No support for /etc/hosts file

G. Hardening Helper::makeResponse so it can make well-formed responses

to malformed requests. (done, may require some code review to make sure) (edit: looks solid)

H. Maybe having a ThreadIf::detach() would be nice. Not addressed, or

discussed. (see [reSIProcate] adding detach to ThreadIf )

The important issues that remain here seem to be B, C and F. For issue B, I am unfamiliar with the form that a solution would take. I have sent mail about C in the thread [reSIProcate] Revisiting parse code for DateCategory, but nobody has responded. I am tempted to let this be. As for F, it looks like this would require messing around with the code in ares, with which I am not familiar. I am tempted to leave this be as well.

Best regards,

Byron Campen

Attachment: smime.p7s
Description: S/MIME cryptographic signature