ent your extensions from registering to your SIP provider, use the no-reg keyword on your ephone-dn number statements. This affects only the SIP connectivity. The normal SCCP phone registration will work just fine: R1-PBX(config-ephone-dn)#ephone-dn 1 dual-line R1-PBX(config-ephone-dn)#number 101 no-reg Chapter 30: VolP If you've decided to actually apply your SIP telephone number to an extension, you can exclude only the extension from registering. I've opted not to do this for the reasons concerning MWI addressed previously. If you want to try this, configure such a scenario like this: -PBX(config-ephone-dn)#ephone-dn 1 dual-line R1-PBX(config-ephone-dn)#number 101 secondary 9735554333 no-reg primary After repeating this for each of our four internal extensions, the SIP registration status looks much cleaner: R1 -PBX#sho sip-ua register stat expires (sec) registered P-Associated-URI 557333333 608222222 Some timers and retry counters that work for me are included next. These all relate to SIP messages and should be fairly obvious based on the command syntax. If you look online for SIP trunking to CME examples, you'll see various versions of these timer values. It may seem odd to have to retry all these SIP messages, but it's not just about packets being lost. I've often seen SIP invites come back "unauthorized," only to have the retry accepted without incident. R1-PBX(config-sip-ua)# retry invite 2 R1-PBX(config-sip-ua)# retry response 3 R1-PBX(config-sip-ua)# retry bye 2 R1-PBX(config-sip-ua)# retry cancel 2 R1-PBX(config-sip-ua)# retry register 10 R1-PBX(config-sip-ua)# timers connect 100 R1-PBX(config-sip-ua)# timers register 250 SIP and NAT SIP doesn't always play well with NAT. Since the SIP messages contain the IP address of the device originating the messages, it's common for them to include private IP addresses, which the receiving device likely won't be able to route properly. On Cisco CME, enter the following commands to make SIP work with NAT: R1-PBX(config)#sip-ua R1-PBX(config-sip-ua)# nat symmetric