Re: [reSIProcate] Open issues for 1.2 release
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@xxxxxxxxxxxx
GERMANY Web: www.terasens.com
______________________________________________
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> 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@xxxxxxxxxxxx
> > GERMANY Web: www.terasens.com
> > ______________________________________________
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
> >> devel-bounces@xxxxxxxxxxxxxxx] 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
> >