Mitel Forums - The Unofficial Source
Mitel Forums => Mitel Software Applications => Topic started by: bigalusn on February 24, 2012, 10:32:59 AM
-
we use (well not use) UCA Ver 4.1 in order to chat and make calls to extensions.
Now if I double click on a contact I can make a call with no problem
but if I right click on a contact I can't or don't get the chat option.
UCA is on 10.10.10.xxx subnet, all MiTel phones are also on this subnet
and all the pc's laptops are on a 192.168.100.xxx
so why don't we get the chat option?
:-\
-
You can either move the UCA server to the same subnet as your PCs, or, open up the necessary ports between the PC subnet and the phone subnet to ensure that all aspects of the UCA Client and Server can see each other.
You can find those ports in the Engineering Guidelines document, and I think I've posted them on this forum as well, as I'm still working to get the softphones portion of the UCA client to work outside of the office.
-
intersting, I was told by BlackBox that we couldn't place the UC server in the same subnet as my Network devices.
but also why wouldn't the chat session work? If I can call and use my softphone I should be able to chat...makes no sense.
What are the specific ports that UCA needs, I don't have a user guide, sorry.
thanks!!!
-
First thing to check is that the users are licensed for this feature.
-
ummm everyone is licensed....
-
They may be licensed but are they enabled for this feature. Go to feature profiles and check that Chat is ticked for the profile your users are using.
-
chat works only if it's on the 10.10.10.xxx subnet, but not on the 192. subnet, so yes everyone has chat enabled...
-
I thought you said chat doesn't work. Do you mean that you took a pc and put it on the same subnet as the uca server and then chat worked? That would tell me it's a firewall issue and that ports need to be opened.
-
Is the 192.168.x.x network in the local networks of the MSL?
-
yes it's in the local msl settings.
Juniper if my firewall and we tested all ports so it's not a firewall issue.
-
Using the UCA engineering guide, page 26 lists the following ports used for the UC Server:
Ports used by UC Server
TCP Ports 5060, 6015, 5090, 5070, 6010, 1099, 5106, 5085, and 5269
SSL ports 5061, 6016, 5091, 5071, 6011, and 5086 (for SIP TLS support)
SSL port 36008 for Web socket support
UDP ports 6015, 5090, 5070, 6010, 5085, and 18100
SonicWall does not list anything as an "SSL Port" so I am not sure what to make of that.
-
Could it be a windows firewall issue in the PC?
-
negative on Windows.
thanks for the ports...
-
ok I think I'm getting closer. I deleted all the users, then ran a Sync, all user are back in (no big deal 64 of 66 users don't have UCA installed) so at least I can test it myself and one other user.
Before all the users under corp contact showed up as "unknown users" now all the users show up normally, just their names
but I still can't freaken chat...
-
just to be sure, both users are logged in and can see each other, including status changes? Do you see the green bubble indicating chat is available?
-
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 :(
-
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 >:(
-
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?"
-
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
-
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...
-
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?
-
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.
-
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.
-
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.
>:(
-
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.
-
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.