Can you outline your call flow? what endpoint are you trying to call? How many SIP phones do you connected to the router on your side?
Also, can you connect a PC to the router and browse to the CUCM? make sure you can login and see the GUI. I just want to make sure you don't have an MTU issue on your VPN tunnel.
How is the SIP phone connected to the UCM? I note that the phone and CUCM IP addresses are 10.10.x.x and 192.168.x.x addresses - normally this are not routable to each other...I would expect the phone and CUCM to both be using 10.10.x.x addresses.
As Joe mentions, can you provide details on the connectivity - VPNs, routers, NATs, etc...?
I believe Teo have a Hardware VPN router connected to their sandbox.
I am just checking the CUCM now.
Our configuration has three Cisco phones, and four Teo phones. The Teo phones can register to 10.10.20.1. The Cisco 7965 can register, and make calls to the Teo phones. The Teo phones receive calls with no problems, and voice traffic sounds fine.
I can browse the CUCM through the router. That's how I set up the phones.
We are using a Cisco 881W for the connection to the sandbox. The 881W NAT address is 192.168.100.0/24.
I see your phones have media termination point checked? is this correct?
My suspicion would be that at some point in the call, CUCM starts attempting to send SIP signaling to the phone's 192.168.x.x address, and this isn't making it back to the phone. Are both Cisco and Teo phones registering with 192.168.x.x addresses?
As it looks like there is a NAT in the scenario somewhere, maybe either the Cisco phones are doing something slightly different in the SIP messaging for it to work, or perhaps the VPN router is fixing up SIP signaling for the Cisco phones via packet inspection...?
Yes, media termination point is checked.
Can you verify that the other no registered cisco phones are getting an IP address from the router? is the TFTP set to 10.10.20.1?
The Cisco phones are configured to use SCCP. The Teo phones will respond to a call made from the Cisco 7965 phone. The 7960 and 7975 phones can contact 10.10.20.1, but seem to have a problem with the provisioning.
I don't see the other cisco phones getting an IP address displayed on the CUCM interface. Perhaps you can reset the settings on those phones and reboot them.
I think that the issue with the Teo phones is the server designates the 3rd-party SIP device as, "Device is not trusted." I configured the 7960 manually for SIP, and it can make and receive SIP calls. The Teo phones can receive calls, but can't make them.
What is the server setting to mark the device as trusted?
The following is a trace from a call between a Cisco 7960 and a Teo phone.
Cisco 7960, caller: 192.168.100.9
Teo, receiver: 192.168.100.4
1 0.000000 192.168.100.4 -> 10.10.20.1 SIP 887 Request: REGISTER sip:10.10.20.1:5060;transport=tcp (1 binding) | 2 0.224263 10.10.20.1 -> 192.168.100.4 SIP 368 Status: 100 Trying | 3 0.226091 10.10.20.1 -> 192.168.100.4 SIP 505 Status: 200 OK (1 binding) | 4 10.203288 192.168.100.9 -> 10.10.20.1 SIP/SDP 824 Request: INVITE sip:email@example.com | 5 10.387322 10.10.20.1 -> 192.168.100.9 SIP 383 Status: 100 Trying | 6 10.409053 10.10.20.1 -> 192.168.100.4 SIP/SDP 1114 Request: INVITE sip:firstname.lastname@example.org:5060;transport=tcp | 7 10.421123 192.168.100.4 -> 10.10.20.1 SIP 410 Status: 100 Trying | 8 10.446648 192.168.100.4 -> 10.10.20.1 SIP 769 Status: 180 Ringing | 9 10.647761 10.10.20.1 -> 192.168.100.9 SIP 708 Status: 180 Ringing | 10 11.785233 192.168.100.4 -> 10.10.20.1 SIP/SDP 1085 Status: 200 OK | 11 11.971925 10.10.20.1 -> 192.168.100.4 SIP 512 Request: ACK sip:email@example.com:5060;transport=tcp;transport=tcp | 12 11.988737 10.10.20.1 -> 192.168.100.9 SIP/SDP 989 Status: 200 OK | 13 12.253308 192.168.100.9 -> 10.10.20.1 SIP 413 Request: ACK sip:firstname.lastname@example.org:5060 | 14 14.920416 192.168.100.4 -> 10.10.20.1 SIP 657 Request: BYE sip:email@example.com:5060;transport=tcp | 15 15.145007 10.10.20.1 -> 192.168.100.4 SIP 424 Status: 200 OK | 16 15.145932 10.10.20.1 -> 192.168.100.9 SIP 503 Request: BYE sip:firstname.lastname@example.org:5060 | 17 15.364620 192.168.100.9 -> 10.10.20.1 SIP 490 Status: 200 OK |
According to what I see in the data, the Cisco phone gives a basic REGISTER and INVITE, while the Teo phone must provide full authentication for REGISTER and INVITE, and the connection gets dropped after initiating an INVITE.
The 'trusted' indicator has to do with secure signaling/media configuration, and shouldn't have any effect on general non-secure calls/operations.
The ability of the 7960 to register with digest authentication credentials is due to use of a proprietary Cisco SIP extension parameter in the Contact header, which functions to uniquely identify the device by its MAC rather than by the digest auth user identify. I don't think this should effect basic SIP calling dynamics either...
Unless there is in fact a NAT in play, or Joe otherwise thinks this could be due to networking configuration, you may need to go ahead and open a DevNet Developer Support ticket to get a detailed analysis of what's happening with this scenario via the CUCM-side logs:
Hi! We are having a problem with our phones initiating a call. They register with no problem, but when I try to make a call from them, the Cisco server ceases traffic. It doesn't close the TCP connection, it just ceases traffic.
I noticed in the server settings that the phone is reported as not being "trusted." Is there a setting to change to mark the phone as trusted?
Cisco server: 10.10.20.1
Teo SIP phone: 192.168.100.4
37 16.823472 192.168.100.4 10.10.20.1 SIP 685 Request: REGISTER sip:10.10.20.1:5060;transport=tcp (1 binding) |
40 17.004746 10.10.20.1 192.168.100.4 SIP 368 Status: 100 Trying |
42 17.005352 10.10.20.1 192.168.100.4 SIP 490 Status: 401 Unauthorized |
44 17.026869 192.168.100.4 10.10.20.1 SIP 887 Request: REGISTER sip:10.10.20.1:5060;transport=tcp (1 binding) |
48 17.250811 10.10.20.1 192.168.100.4 SIP 368 Status: 100 Trying |
49 17.252388 10.10.20.1 192.168.100.4 SIP 506 Status: 200 OK (1 binding) |
50 17.253516 10.10.20.1 192.168.100.4 SIP 594 Request: NOTIFY sip:email@example.com:5060;transport=tcp |
52 17.353075 192.168.100.4 10.10.20.1 SIP 694 Status: 200 OK |
198 83.101543 192.168.100.4 10.10.20.1 SIP/SDP 1221 Request: INVITE sip:firstname.lastname@example.org:5060;user=phone |
202 83.287388 10.10.20.1 192.168.100.4 SIP 392 Status: 100 Trying |
203 83.287671 10.10.20.1 192.168.100.4 SIP 539 Status: 401 Unauthorized |
205 83.303909 192.168.100.4 10.10.20.1 SIP 396 Request: ACK sip:email@example.com:5060;user=phone |
206 83.315357 192.168.100.4 10.10.20.1 SIP/SDP 1425 Request: INVITE sip:firstname.lastname@example.org:5060;user=phone |