Wolfgang,
I haven't seen this problem; however, I'm guessing that we aren't shutting something down and/or we aren't restarting something correctly (some static??). I would make sure that all of our threads are shutdown after unitialize. ... I'm guessing that we did not shutdown the OsNatAgentTask?
On 8/9/06, Wolfgang Pichler <[EMAIL PROTECTED]> wrote:
Hi all,
its me again with the next problem...
To be able to deal with lost network connections i do have made the
following...
Check the network connection -> go into idle state if it fails -> check
for a new network connection -> on new connection do call sipxReInitialize
I think thats the best way at time to deal with lost connections (any
other thoughts ?)
The problem now is - the after the call to sipxReInitialize the
SipClient is unable to read incoming messages
The SipClient does hang in the call to: bytesRead =
message->read(clientSocket, readBufferSize, &buffer); (around line
SipClient.cpp:274)
I do have added a debugging message before this call, and after this
call, to get some details about the clientSocket - it just gives me the
following which does seem to be pretty correct
before i call sipxReInitialize i will get the following:
"WP: SipClient::Attemp message->read. Local 10.0.1.184:1830, Remote:
0.0.0.0:0 . Socket Descriptor: 5248"
"WP: SipClient::message->read returned 543 bytes. Local 10.0.1.184:1830,
Remote: 0.0.0.0:0"
and the ethereal trace does show me that the message was coming in on
port 1830
after i have called sipxReInitialize i will get the following
"WP: SipClient::Attemp message->read. Local 10.0.1.184:1854, Remote:
0.0.0.0:0. Socket Descriptor: 5432"
here it hangs
and the ethereal trace does show me that the message was coming in on
port 1865 - not 1854 where the client is listening !!
Something else i have noticed is (i am using STUN)
before the ReInitialize - the STUN Request was done using the same port
as the SipClient uses to read messages (which does seem to be pretty
clear - because you can use STUN as NAT keepalive)
after the ReInitialize - the STUN Request was done using port 1854 - the
Response was also to port 1854 - so STUN Success - the SipClient is
listening on 1854 - as expected - but the SipClient is sending out the
Message on Port 1865 - so the response comes to 1865 - but no SipClient
is listening on 1865 !!!
Before i try to fix this on my own - i wanted to ask here if someone
does already seem to know where the problem is ?
regards,
Wolfgang
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
