1 2 First Previous 16 Replies Latest reply on Mar 8, 2016 11:43 PM by Teo7810TSG6

    3rd party SIP phone loses traffic after INVITE

    Teo7810TSG6

      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:1090@192.168.100.4: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:1094@10.10.20.1: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:1094@10.10.20.1:5060;user=phone |

      206 83.315357       192.168.100.4 10.10.20.1      SIP/SDP 1425 Request: INVITE sip:1094@10.10.20.1:5060;user=phone |

        • 1. Re: 3rd party SIP phone loses traffic after INVITE
          jokearns

          Hi Chuck,

           

          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.

           

          Regards,

           

          Joe

          • 2. Re: 3rd party SIP phone loses traffic after INVITE
            dstaudt

            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...?

            • 3. Re: 3rd party SIP phone loses traffic after INVITE
              jokearns

              I believe Teo have a Hardware VPN router connected to their sandbox.

               

              I am just checking the CUCM now.

               

              Joe

              • 4. Re: 3rd party SIP phone loses traffic after INVITE
                Teo7810TSG6

                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.

                • 5. Re: 3rd party SIP phone loses traffic after INVITE
                  Teo7810TSG6

                  We are using a Cisco 881W for the connection to the sandbox.  The 881W NAT address is 192.168.100.0/24.

                  • 6. Re: 3rd party SIP phone loses traffic after INVITE
                    jokearns

                    Chuck,

                     

                    I see your phones have media termination point checked? is this correct?

                     

                    Joe

                    • 7. Re: 3rd party SIP phone loses traffic after INVITE
                      dstaudt

                      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...?

                      • 8. Re: 3rd party SIP phone loses traffic after INVITE
                        Teo7810TSG6

                        Yes, media termination point is checked.

                        • 9. Re: 3rd party SIP phone loses traffic after INVITE
                          jokearns

                          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?

                          • 10. Re: 3rd party SIP phone loses traffic after INVITE
                            Teo7810TSG6

                            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.

                            • 11. Re: 3rd party SIP phone loses traffic after INVITE
                              jokearns

                              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.

                               

                              Joe

                              • 12. Re: 3rd party SIP phone loses traffic after INVITE
                                Teo7810TSG6

                                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?

                                • 13. Re: 3rd party SIP phone loses traffic after INVITE
                                  Teo7810TSG6

                                  The following is a trace from a call between a Cisco 7960 and a Teo phone.

                                  Server: 10.10.20.1

                                  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:1090@10.10.20.1 | 
                                    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:1090@192.168.100.4: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:1090@192.168.100.4: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:1090@10.10.20.1:5060 | 
                                   14  14.920416   192.168.100.4 -> 10.10.20.1   SIP     657   Request: BYE sip:1010@10.10.20.1: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:1010@192.168.100.9: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.

                                  • 14. Re: 3rd party SIP phone loses traffic after INVITE
                                    dstaudt

                                    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:

                                    https://developer.cisco.com/site/devnet/support/

                                    1 2 First Previous