Re: [reSIProcate] Open issues for 1.2 release
Agreed!
Matthias
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Freitag, 21. September 2007 22:04
> To: Matthias Moetje
> Cc: resiprocate-devel
> Subject: Re: [reSIProcate] Open issues for 1.2 release
>
> 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@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
> >>>
> >