That's good info. So from what you're saying, you can register the 9971 phone when it is plugged in at the HQ location but doesn't register when you take it to the branch site. From a port perspective, you simply need 5060 TCPand UDP ports opened:
From (Sender)
To (Listener)
Destination Port
Purpose
Phone
Unified CM
5060 / TCP and UDP
Session Initiation Protocol (SIP) phone
Unified CM
Phone
If that is already taken care of, then let's look at taking a packet capture from the phone as well as the UCM node to which it should register, so we can see what's going on.
That's good info. So from what you're saying, you can register the 9971 phone when it is plugged in at the HQ location but doesn't register when you take it to the branch site. From a port perspective, you simply need 5060 TCPand UDP ports opened:
From (Sender)
To (Listener)
Destination Port
Purpose
Phone
Unified CM
5060 / TCP and UDP
Session Initiation Protocol (SIP) phone
Unified CM
Phone
If that is already taken care of, then let's look at taking a packet capture from the phone as well as the UCM node to which it should register, so we can see what's going on.
If your 9971 phone (SIP) registers at HQ, and then moved to branch site and doesn't register, then it's definitely a network issue. The packet capture path you are heading down is the correct and will give you more insight on 5060 UDP/TCP.
However, a common problem that gets alot of people is that a SIP phones won't register if it doesn't have a configured DN. DN is mandatory for SIP phones to register. SCCP phones do not need a DN for it to register and can register without DN. Just wanted to make sure this was not the case for you.
CTL file comes into the picture if it is a secure cluster. Is yours a secure cluster? I'm assuming you tried resetting the phone to factory defaults? If not, please do so. You can also try deleting the ITL file from the phone (it doesn't get removed with a factory reset). Are you able to pull the config file of the phone from the TFTP server at the branch location? My guess is that is working since you see the phone's auto register DN in the CUCM. If all else fails, please collect detailed CUCM SDI and SDL traces, detailed TFTP traces and possibly a packet capture of the phone once you reset it. Provide the IP address, MAC address of the IP phone, IP address and hostnames of the CUCM servers in the cluster, timestamp of when you reset the phone.
i am not using secure cluster, i already reset the phone to factory default (using the option in adminstrator > reset > reset all), but the still get rejected.
how do i erase ctl in 9971? if i am using sccp ip phone i can unlock by using **#, but in SIP phone that command seems doesn't work.
My tftp server is in HQ too, how do i pull config from tftp? never done this before
is there any ohter port that should open?
i add the capture, i can see port 2445, should i open that port?
I reviewed the packet captures and I can see that the config file is successfully downloaded by the phone. However I believe you have filtered the capture and I do not see any SIP messages in the captures.
The way to pull the config file of the concerned phone is:
1> Open a command line window.
2> Type: tftp get SEP10BD18DC89DA.cnf.xml.sgn
If you can successfully download the file, you know that the file exists in the TFTP and you can retrieve it at the same remote location as where the IP phone is. Hence there should be no firewall issue.
Can you please send the entire packet capture along with CUCM SDI and SDL traces from the node to which it should register to?
Is that the TFTP server on which you ran the utils network capture command? If yes, please run it on the CUCM node to which the phone should be trying to register to. You can check the Device Pool --> Call Manager Group as per that Phone's config in CUCM.
Also, please pull the detailed CUCM SDI and SDL traces from all nodes in the cluster for the same duration while you run the utils network capture. Please provide the IP address, MAC address of the IP Phone, IP address and hostnames of the CUCM nodes in the cluster.
