I have an attendant console user that is running on a pc behind a natted firewall. The CCM box is on the outside of the firewall. The attendant console can log and take calls, transfer calls etc.. . All seems to work except the line appearance state only shows a question mark (?). If I move the attendant console pc to the outside of the firewall then the line status infor works correctly.
What is needed to pass line status through a firewall?
The Line State is supplied over UDP. If the UDP port is not spcified the port is selected at random. The UDP port can be specified on the client PC using the using Advanced Settings Dialog. You can specify a free UDP port as "IP Address:UDP port" in the "Local Host IP Address (for line state)" field: under Advanced Tab of Attendant Settings Dialog Box.
I tried to do a one to one static nat assignment. I statically assigned the ip address of attendant pc to a public address. I didn't specify tcp or udp but an entire ip address one for one. I don't have any accesslists or filters blocking incoming traffic to the public address that is natted to the attendant's pc.
Still no line status.
Any other ideas? Have you tried this successfully?
I currently have TAC case F206015 open regarding this same issue. The technical answer is "this is not supported", however, I am in the process of filing a PERs in order to help my customer out.
Working theory I have is that the registration process (where the AC client tells the LSS server where to send the updates to) is within the payload, and thus is not NATd. So the LSS server sends LSSs to the non-NATed (and hence, unreachable) address.
I have a theory that you could do this, but have yet to test it: create an aliased host address with the same IP that you have the static 1:1: NAT for, netmask /32. Manually bind AC Client's LSS to that IP address. This will succeed since that IP actually exists on the local machine. Then when the AC client registers with the LSS, the packets will end up going to the outside (NAT'd) address, then get NAT'd in.
The only catch here is if the AC Client is bound specifically to that feigned IP; when the packet arrives it is destined for the normal address (per the NAT rue) and not the spoofed /32, so this may or may not work. It's just a theory at this point.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...