reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

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