Hi Bob, why does the sip clients get created for such short usage - is there a problem if i do use the same sip client instanz for a longer time ?
I do have changed it already so that getClient does return a valid sip client - and it seems to work perfectly. So creating a sip client for each request, and then letting it get destroyed instead of reusing it seems not very efficient. getClient does not return an existing SipClient instanz because it can't find a instanz which matches the remoteIP and remotePort values - the values do not match because of the do not get set right. In the constructor of the SipClient there is a call to a function which should return the remoteIP and remotePort from the socket descriptor- but this call fails because of the socket is not connected at the time of the call. So, should we create a new function to set these variables by an extra call - or should we call a "setRemoteValues" function after the socket connect (if this is possible). I do have done something very simple - which does work - but is not the way to go. I have added new parameters to the constructor to set the remoteIP and remotePort on construction. So, any idea about this ? regards, Wolfgang Bob Andreasen schrieb: > 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/
