Re: Re: Via header issues while talking to OCS Access Edge Server

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.

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. This is a performance optimization.
Indeed your application should not ( ideally ) depend upon this
setting.


Thanks for sharing your experiences.

Regards,

NeoNxP Ranga

On Sun, Jun 29, 2008 at 6:08 PM, SanNxP <[email protected]> wrote:
> Jeroen van Bemmel <jbemmel <at> zonnet.nl> writes:
>
>>
>> San,
>>
>> You've picked a challenging task, this vendor is not known for their
>> interoperability capabilities or adherence to open standards...
>
> But I am hoping they would have documented their extensions well. I found this
> one http://download.microsoft.com/download/1/6/F/16F4E321-AA6B-4FA3-8AD3-
> E94C895A3C97/%5BMS-SIPRE%5D.PDF .
>
>>
>> Having said that, the routing for the request in the reverse direction
>> (NOTIFY) is governed by the Contact header (or Record-Route for
>> proxies), not the Via header.
>
> Yes, I know. I'll try to explain. The "200 OK" response to the original
> SUBSCRIBE used the Via header and it used the open connection on which AES
> received the request. The Via header mentioned port 5061 but AES noted the
> actual port as 1696 (some ephemeral port used by the Jain-SIP client side) and
> decided that NATting was going on. Then when it needed to send the NOTIFY
> request to my proxy it did use the Record-Route from my original SUBSCRIBE (or
> the Route header in the NOTIFY itself) to forward the NOTIFY to my proxy. The
> Route header happened to point to my proxy at port 5061 but it knows (wrongly)
> from its connection pool/table mechanism that NATting was going on and hence
> tried to use the existing connection on which it sent the "200 OK" response
> back. Since that connection was closed and it could not open a new connection
> to port 1696 it generated an error saying some thing like "No existing
> connection found, load balancer or firewall problem?"
>
> I studied the above document from Microsoft (specifically sections 3.4 and
> 3.4.5.1) to arrive at my analysis. Also when I analyzed the SIP messages
> between Microsoft SIP elements they do use ephemeral ports in their Via
> headers and that seems consistent with my analysis. I don't know if in this
> case they are not following the standard properly, if the standard is vague in
> this area or if they are following the standard too strictly.
>
>
>> Using the ephemeral port in the Via won't
>> help. In general, TLS connections pose a problem, because by default SIP
>> does not reuse connections in the reverse direction.
>
> Does it mean then setting gov.nist.javax.sip.CACHE_CLIENT_CONNECTIONS  to true
> (as you suggest below) either won't help or is not correct?
>
>
>> You'd normally have
>> 2 connections, but not all elements support that (because they don't all
>> have a server certificate). See SIP outbound and SIP connection-reuse
>> drafts for solutions under construction (but likely not implemented in
>> your environment yet)
>
> I don't really want connection re-use (except for responses to requests)
> except to interoperate with OCS. I am sure there is a simpler mechanism (such
> as setting ephemeral port in the Via header) that should work.
>
>
>>
>> You could try to prevent the closing of the connection by the Jain-SIP
>> stack. The property gov.nist.javax.sip.CACHE_CLIENT_CONNECTIONS controls
>> the closing of TCP/TLS connections after receiving a response, by
>> default (true) they are not closed. What setting do you use?
>
> Thanks for the pointer. I looked up the documentation for this one and it is
> kind of confusing, but I'll follow this up.
>
>>
>> Regards,
>> Jeroen
>>
>
>
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>



-- 
M. Ranganathan