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

San,

You've picked a challenging task, this vendor is not known for their 
interoperability capabilities or adherence to open standards...

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. 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. 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)

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?

Regards,
Jeroen

SanNxP wrote:
> Hi,
>
> I am trying to use the Jain-SIP stack and the proxy to talk to Microsoft OCS. 
>
> There is a peculiar problem I am noticing: when my proxy forwards a message 
> (say SUBSCRIBE) to the OCS Access Edge server (AES) it adds the Via header 
> with the SIP listener's IP, port, transport (e.g. 17.1.16.1:5061, 
> transpost=tls). Note that it uses the listening port 5061 however when it 
> connects to the AES as a client it has a different ephemeral port bound to the 
> local socket. The AES records the ephemeral port as the port from which it 
> actually received the message and because there is a mismatch between what the 
> Via header says (port=5061) and the actual port, it decides that NATting is 
> going on. Then when the AES needs to send another request (say NOTIFY) back to 
> my proxy as part of the same dialog to (17.1.16.1:5061,transport=tls) it 
> decides that because of NATting it should be using the same connection on 
> which it received the SUBSCRIBE. However my Jain-SIP proxy closed the 
> connection after receiving the 200 OK (to the original SUBSCRIBE) on that 
> connection. The AES then barfs saying that it didn't find any open connection 
> to send the NOTIFY instead of trying to open a connection to 
> (17.1.16.1:5061,transport=tls).
>
> I am not sure if OCS/AES is doing it right as per RFC3261 but how do I solve 
> this problem? I am planning to modify the Jain SIP stack to use the actual 
> ephemeral port in the Via header to make OCS/AES happy. Any other suggestions?
>
> San
>
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>
>