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

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
>