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.