Hi, i am using UDP with rport enabled
regards, Wolfgang Bob Andreasen schrieb: > 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/
