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/
