On Sunday, August 20, 2006, 10:50:45 AM, Wolfgang Pichler wrote: > 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 ? Under UDP, it helps detect early call failures. Dan Petrie is a better expert on this, but from what I understand: if you reuse the same SipClient/Datagram socket for multiple remote targets, it isn't possible to pick out the ICMP errors and fail calls immediately when the remote port isn't open -- you will end up resending and waiting until the SIP timers expire. The data seems to be available in the ICMP response, but the socket APIs don't allow you to pick it out the info. However, if you have a single purpose Datagram socket/SipClient you can detect this. > 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. Agreed, although rport (poorly named in sipXtapi) should do the trick under UDP. It will reuse the same SipClient / Datagram socket for ALL signaling. If you are using TCP, there are security issues and you need to add some additional logic on top of those (see the IETF drafts on connection reuse / outbound). > 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). ... it sounds like we have a bug. Are you using TCP or UDP? I keep pushing rport for UDP, because it is required for NAT traversal. > 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/
