Hi Wolfgang, The sipxReInitialize docs have been updated to indicate that you must configure the new instance (e.g. rport, outbound proxy, etc.).
As for getClient -- I highly recommend using rport -- Infact, I will likely change the behavior to enable it by default. Alternatively, as you pointed out, we create ephemeral sip clients. - Bob On Sunday, August 13, 2006, 1:20:11 PM, Wolfgang Pichler wrote: > 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/
