UCA Ver 4.1, unable to chat, different subnets...

[bigalusn]

yes I can see the green bubble.

Another thing that keeps happening, we both go "off line" after a certain time (I haven't timed it but maybe 15 mins)
but in the Chat Settings I have that un-checked so it should never say away...but that one we can get back to.

still can't chat

[bigalusn]

from UCA server, under a user's profile I can select several License Features: if I start choosing the options, and log out of UC and log back in my features change.  So I'm thinking this could be a programming bug.

if I select Default Feature Profile, UC comes up correctly, but still can't chat.
if I select Basic Profile, UC comes up by my other users say "status unknown" I'm sure its because they don't have UC installed on their pc's/laptops
If I select Desktop plus Mobile my UC comes just fine, but user number # goes directly off line...

bottom line we still can't chat 

[Mattmayn]

Under the features tab (admin interface on the server) If you click on one of the feature profiles does it show the chat feature as "used?"

[boycey9]

My view on this is that you need to prove the firewall is not an issue, Set up a new subnet on a test router and plug your pc in the back, use a bit of static routing etc to prove that this will work with your config as is. There are two many variables to just change things they need to be eliminated.
If it turns out to be the firewall try removing SIP from the ALG

[bigalusn]

ok this is still open, I was away from the office for a few weeks.

well I know it's not my firewall, I have 3 subnets and I've changed IP's on the other two, so we still can't chat on 192.168 subnet but we can chat on 10. subnet.  10 subnets handles all IP phones and all voip equipment.

but I can make a call from UCA on any subnet, so why doesn't the simple chat work...

[v2win]

Is there any way you have have a data switch or router do the L3 routing and not the firewall to remove it from the equation?

[akuhn]

In looking at your last post, you question why won't chat work when calling does?  The answer to that is they are two different things that use two different resources. 

I had it the other way around.  I could chat, but not call.  The issue turned out to be an incorrect external IP address for the PBX in my UCA server. 

Since you can call from the UCA, that means that the UCA Server is directing the UCA Client to your PBX.  That's good.  Those three things are talking to each other the way they should. 

But for the UCA Server and Client to allow chat means in your case a lot of cross subnet communications from the 10.X subnet to the 192.168 subnet.  And the PBX has nothing to do with that.  So, I think you still need to validate that all of those port openings that I've listed in other postings on this board are open between your workstations and the UCA server.  Unless all ports are open, then you need to check the list of ports required vs. what you actually have.  And if you don't have access to the firewall, then you're going to need to grab your firewall person and sit down with him/her and work this out - just to rule it out.

[bigalusn]

no, I don't...I used the firewall so I can avoid DHCP usage from windows server, so my firewall assignes all our phones IP addresses from the 10 network.

[bigalusn]

akuhn,

thanks for your reply. I've contacted Juniper tech support and we gone over the ports and even created a policy to allow all ports from 10 to 192, so they concluded that it wasn't the firewall.  All proper ports are open on the firewall.

 

[Kurt]

If you have access to a Teleworker/Mitel Border Gateway server, you could always use the TNA [Teleworker Network Analyzer] on a PC in the 192.X problem subnet, type in the UCA server as the Teleworker IP address, and test the ports.  This will tell you that your ports are open/closed/timeout.

If they are open, the next step I would take is a wireshark.  Mirror on of your ports running the problem UCA clients and capture the info.  Place the test chats/calls, and verify if you see SIP data in your wireshark from that Client PC.  See if the data is actually traversing the subnets/network now that you verified through TNA and Juniper that the ports are open.

[boycey9]

Im afraid to say that you still have not eliminated the firewall, you have just confirmed that the ports are open.
As I said before you could try turning off SIP on the ALG, just untick the box, this stops many Mitel SIP apps from working.
Far short of this you really need to fully eliminate the firewall, ie remove it from the equation, its the only true way to fault find.
I have two offices connected by VPN's on netscreens and have chat working on 4.2 and 5.0 since the other day so it will work.