[reSIProcate] Open issues for 1.2 release

Fri Sep 21 15:03:48 CDT 2007

	Ok, I see what you're getting at here. I suppose a lighter  
alternative would be to use a callback, but since there are not very  
many UdpTransport objects, the extra space doesn't matter at all, and  
the mutex will only be locked if the app decides to send STUN  
requests. I guess there isn't too much reason to mess with the  
current scheme.

Best regards,
Byron Campen

> When the application adds a transport it can get
> a pointer to it (UdpTransport). It then utilizes the
> UdpTransport to send STUN tests and retrieve the
> response at a later time. UdpTransport processes
> the STUN responses on the stack's thread while
> the application calls ::stunResult from its
> own thread. Therefore the mutex is required to
> protect the results of the STUN test.
>
> Why all this? Because we need access to the
> transport's socket. Background:
>
> An application cannot send STUN tests on its own
> because the STUN test needs to be sent and received
> on the same interface/address/port (>>socket) as
> the stack itself and I found no viable way for
> sharing a socket with the stack (I think there is
> none, at least not on Windows)
>
> Some time ago people had plans for creating a
> new message type for STUN tests and let these STUN
> messages and responses travel all the way through
> the stack. To me this seems like a lot of effort
> for little benefit, at least as long as there aren't
> any new STUN features which would really require
> this.
>
>
> Back to the mutex:
>
> In ::stunSendTest we are building the STUN request
> and the only action we are performing which is
> interfering with the stack in any way is mTxFifo::add
> This ::add method has got its own mutex, so
> the mutex in ::stunSendTest can be removed.
>
> On the other hand it should not have any serious
> performance impact because the function is not
> called very often and doesn't do much anway.
> A reason to leave it there, could be that the
> function itself remains thread-safe (for
> possible future changes).
>
>
> Best regards,
> Freundliche Grüße,
>
> Matthias Moetje
> ______________________________________________
>
> TERASENS GmbH       Phone:  +49.89.143370-0
> Augustenstraße 24   Fax:    +49.89.143370-22
> 80333 Munich        e-mail: info at terasens.com
> GERMANY             Web:    www.terasens.com
> ______________________________________________
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: Byron Campen [mailto:bcampen at estacado.net]
>> Sent: Freitag, 21. September 2007 19:41
>> To: Matthias Moetje
>> Cc: resiprocate-devel
>> Subject: Re: [reSIProcate] Open issues for 1.2 release
>>
>> 	So, what is going to be calling UdpTransport::stunResult()
>> anyway?
>> Why do we need a mutex in the first place?
>>
>> Best regards,
>> Byron Campen
>>
>>> Hi Byron,
>>>
>>> if you want to start with something very easy:
>>>
>>> #23 can be eliminated by deleting the first line ("resip::Lock lock
>>> (myMutex);") of function UdpTransport::stunSendTest.
>>>
>>> Unfortunately I can't do it at the moment as I have no current
>>> working copy...
>>>
>>>
>>> Best regards,
>>>
>>> Matthias Moetje
>>> ______________________________________________
>>>
>>> TERASENS GmbH       Phone:  +49.89.143370-0
>>> Augustenstraße 24   Fax:    +49.89.143370-22
>>> 80333 Munich        e-mail: info at terasens.com
>>> GERMANY             Web:    www.terasens.com
>>> ______________________________________________
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: resiprocate-devel-bounces at resiprocate.org  
>>>> [mailto:resiprocate-
>>>> devel-bounces at resiprocate.org] On Behalf Of Byron Campen
>>>> Sent: Freitag, 21. September 2007 17:43
>>>> To: resiprocate-devel
>>>> Subject: [reSIProcate] Open issues for 1.2 release
>>>>
>>>> 	We have a fairly large rundown this time around. I encourage
>>>> anyone who has time to investigate these, and send your thoughts. I
>>>> have only done a cursory look-through, so I will be taking a closer
>>>> look at these also over the next week.
>>>>
>>>> Open issues:
>>>>
>>>> 1. [reSIProcate] [ReSIProcate_1.1_RC2] submit a patch for DUM/
>>>> ClientPublication.cxx (reSUBSCRIBE/412 response is not reacted to
>>>> correctly) (old issue, need to revisit)
>>>> 2. [reSIProcate] 180 Ringing and 200 OK messages with incorrect
>> port?
>>>> (looks like this is a complaint about resip sending responses on  
>>>> the
>>>> same TCP connection the request came in on?) 3. [reSIProcate]
>> Problem
>>>> with DNS and mActiveQueryCount (reference count might not be
>>>> functioning correctly; might have been using old
>>>> version)
>>>> 4. [reSIProcate] about thread safe of repro! (thread-safety issues
>> in
>>>> the various XStore classes in repro) (looks resolved) 5.
>>>> [reSIProcate]
>>>> build warnings on FreeBSD 6.1 (comparison between signed and
>> unsigned
>>>> integer expressions; macro definition of FD_SETSIZE is an unsigned
>>>> int
>>>> under FreeBsd) (looks fixed, by ekr) 6. [reSIProcate] SDP in ACK
>>>> after
>>>> intial offer/answer exchange causes BYE from resip/dum (looks like
>> we
>>>> might be overreacting to unexpected SDP here, maybe apply Postel's
>>>> maxim) 7. [reSIProcate] repro TLS : sending responses (is probably
>>>> caused by someone using the old sipfoundry.org repository, maybe
>>>> follow
>>>> up) 8. [reSIProcate] Adding a new parameter to a header (RFC 3329
>>>> params were not supported) 9. [reSIProcate] Remote-Party-Id  
>>>> Header -
>>>> Should it be a part of the Stack (non-standard header type support
>>>> request) 10. [reSIProcate] Resiprocate Client with OpenSER
>>>> server.....trying to establish TLS connection :- Error when
>> verifying
>>>> server's chain of
>>>> certificates: unable to get local issuer certificate (there might
>>>> still
>>>> be a problem here, need to give it a look) 11. [reSIProcate]
>>>> Performance of a P2P-over-SIP program using resiprocate (oddball
>>>> retransmission behavior) 12. [reSIProcate] segfault in
>>>> SdpContents::Empty when linking statically (static destruction
>>>> problem... no idea what might be going on here) 13. [reSIProcate]
>> RPM
>>>> specfile for resiprocate stack (looks like Alfred put forth the
>>>> effort
>>>> to write a spec file for the resip stack, should give it a look)  
>>>> 14.
>>>> [reSIProcate] [reSIProcate 1.1 stack]How to use ? (looks like  
>>>> shared
>>>> lib badness) 15. [reSIProcate] sip stack process CANCEL problem?
>>>> (stack
>>>> not sending TransactionTerminated for stuff torn down by CANCEL?)
>> 16.
>>>> [reSIProcate] Assert in DialogSetId, issue with from to tag (bad
>>>> assert
>>>> on garbage from wire?) 17. [reSIProcate] Leaking transactions
>>>> (leak in
>>>> repro; at one point I looked into this, need to swap that info
>>>> back in)
>>>> 18. [reSIProcate] Memory leaks in SipStack::send(.) and
>>>> SipStack::post
>>>> (.) ? (memory leaks in DUM?)
>>>> 19. [reSIProcate] error: extra semicolon (funky macro warnings) 20.
>>>> [reSIProcate] repro crash during load test (crash in old version of
>>>> repro) 21. [reSIProcate] Bug in ClientRegistration::removeBinding
>>>> (really, _really_ broken code in ClientRegistration from back
>>>> when) 22.
>>>> [reSIProcate] RecursiveMutex for APPLE and INTEL_COMPILER 23.
>>>> [reSIProcate] mutex in UdpTransport (unnecessary mutex) 24.
>>>> [reSIProcate] DUM and DumShutdownHandler Implementation
>>>> (unimplemented
>>>> params, should either implement, or remove) 25. [reSIProcate]  
>>>> Issues
>>>> with ClientSubscription issuing local 408 timeouts (looks like
>>>> someone's firewall was eating packets, need to
>>>> verify)
>>>> 26. [reSIProcate] Terminated Subscription (oddness with callbacks)
>>>> 27.
>>>> [reSIProcate] Query regarding queuing mechanism for NOTIFYs
>>>> (ClientSubscription)
>>>> 28. [reSIProcate] Call disconnect due to re-invite timeout (dialog
>> is
>>>> getting torn down on reINVITE timeout, because remote UA has issued
>> a
>>>> target refresh _after_ the reINVITE was sent, and stopped
>>>> listening on
>>>> the old interface) 29. [reSIProcate] [PATCH] fix for compiling
>>>> SipDialer example (resolved) 30. [reSIProcate] NULL pointer  
>>>> crash in
>>>> DialogSet::dispatch with mAppDialogSet (possible race condition
>> crash
>>>> in DUM) 31. [reSIProcate] [Patch] Fix XCode project file
>>>> (resolved) 32.
>>>> [reSIProcate] Endless loop? (loop in DUM message-passing dealing
>> with
>>>> refer) (resolved) 33. [reSIProcate] NOTIFY without content-type
>> (have
>>>> to give this a closer look) 34. [reSIProcate] Authentication failed
>>>> (possible digest problem) 35. [reSIProcate] ParseBuffer::Exception
>>>> thrown in
>>>> XMLCursor::firstChild()
>>>> 36. [reSIProcate-users] Authentication failed
>>>>
>>>> Best regards,
>>>> Byron Campen
>>>
>

-------------- 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/20070921/8bc19834/attachment.bin>