Re: Via header issues while talking to OCS Access Edge Server
SanNxP <[email protected]> Mon, 30 Jun 2008 19:50:53 +0000 (UTC)
| Newsgroups | gmane.comp.voip.nist-sip |
|---|---|
| Message-ID | <[email protected]> |
M. Ranganathan <mranga <at> gmail.com> writes: > > Hello SanNxP (interesting Nom de plum), > > Just a couple of quick additions to Jeroen's excellent tips: > > 1. Jain SIP uses symmetrical signaling (has been doing so for a couple > of years at least). It is not using some ephemeral port for the > socket. That's interesting. When you connect to the remote end point (the OCS AES) as a client socket, the implementation normally uses ephemeral ports. You can probably bind it to a specific port (say 5061) but in this case that would fail too, since port 5061 would be in use by the listener that was created. So my assumption is that the client socket does use an ephemeral port also as confirmed by the AES logs I am seeing. I think by symmetric signalling you imply that the client socket that was created to connect to AES to send the SUBSCRIBE is left open to receive more messages - more than just the response to the request that was sent. Is that correct? > > 2. CACHE_CLIENT_CONNECTIONS is relevant for TCP signaling. You can set > that to true and your client will not drop the connection after > transaction termination. Rather it will re-use that connection for the > next interaction with the server. Are you saying the connection can also be used by the other end to send more requests (and not just a response) as is happening in my case? In that case setting this to true might be the solution. The only thing is the doc at http://snad.ncsl.nist.gov/proj/iptel/jain-sip-1.2/javadoc/ says the following about this: gov.nist.javax.sip.CACHE_CLIENT_CONNECTIONS = [true|false] Default value is true. Setting this to true makes the Stack close the server socket aftera Client Transaction goes to the TERMINATED state. This allows a client release any buffers threads and socket connections associated with a client transaction after the transaction has terminated at the expense of performance. Is the above description correct? Shouldn't it be "...Setting this to false makes the Stack close the client socket after a Client Transaction goes to the TERMINATED state..." > This is a performance optimization. > Indeed your application should not ( ideally ) depend upon this > setting. > > Thanks for sharing your experiences. > > Regards, > > NeoNxP Ranga > :-) Welcome to NxP.