Hi all, as it seems - after calling the sipxReInitialize you have to set all the config options as you do after sipxInitialize...
The problem was that the option to use the rport wasn't set - and so it caused this behaviour... Another thing i encountered while watching the code... In the SipProtocolServerBase Class - createClient function... This function does return a SipClient instanz - as far as i can see it should return an existing instanz if it matches on remoteHost and remotePort and local IP... There is a call to: SipClient* client = getClient(hostAddress, hostPort, localIp); This call should return an existing SipClient - but call does not return anything any time... So it does always create a new clientSocket - and then a new SipClient Class and does return the new created class... So, why does it not can reuse the already created class ? Isn't this a waste of ressources ? Can someone else please try this ? regards, Wolfgang Bob Andreasen schrieb: > 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] > <mailto:[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 > <http://10.0.1.184:1830>, Remote: > 0.0.0.0:0 <http://0.0.0.0:0>. Socket Descriptor: 5248" > "WP: SipClient::message->read returned 543 bytes. Local > 10.0.1.184:1830 <http://10.0.1.184:1830>, > Remote: 0.0.0.0:0 <http://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 > <http://10.0.1.184:1854>, Remote: > 0.0.0.0:0 <http://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] > <mailto:[email protected]> > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ > <http://list.sipfoundry.org/archive/sipxtapi-dev/> > > _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
