[reSIProcate] Open issues remaining for 1.1 release

Tue Feb 20 16:35:32 CST 2007

	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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070220/b0aaeacb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070220/b0aaeacb/attachment.bin>