If this is a 3pcc phone, I have raised this with Cisco and unfortunately they have classed it as a feature request rather than a critical bug. F2585 In my case, I am trying to invoke reverse lookup to LDAP. The explanation given was that if the incoming call has a textual description of the calling party, the phone assumes this has been intelligently populated and doesn’t bother to reverse lookup. Eg in "" From: "+443330237000" <sip:+443330237000@10.200.61.132>;tag=tBQv6c0y9rXQH   Although the logic carries some merit, in my view it's incorrect as the user is not in control of that field and should be able to instruct the phone to reverse lookup unilaterally. (like yealink etc)   By the way - if the phone has a local contact, the phone does lookup in that database - just not external ones.   It would help massively if you could ask Cisco to prioritise F2585   Adam ... View more

Ok. Pass. Just check that you are pinging from interface 302   i imaging you are learning about the x.64.x route from ospf.  ... View more

1. 64.11 sends an invite to the cube at 65.254. cube responds back with a 100 trying   2. 65.254 send an invite to 65.11 65.11 reponds back with 100 trying 180 ringing   3. cube sends 180 back to 64.11 (check point)   4. 65.11 sends 200 OK   5. Cube sends back ack to 65.11 straight away,   6. cube 65.254 send 200OK to originating CM at 64.11   7. cube does not get an ACK and retransmits the 200   8. you give up and 65.12 send a BYE   9. Bye is Ack by the cube straight away   10. Bye is send to 64.11 from cube but is not acked by 64.11 ;-(       It looks to me that there is a firewall or something blocking udp sip messages from 65.254 to 64.11 or perhaps's there's an IP route missing on the cube. Can you ping 64.11 from 65.254 ?? I suspect you did not hear ringback on the originating handset - see step 3. This would indicate that 64.11 did not receive the 180 ringing   The ack sent by the cube in step 5 and 10 indicate you're cube is in a super b2b mode which is quite fancy. I'm not actually familiar in how this is configured on a cube, so once this is fixed, It would be nice if you could share your config with me.   Good luck   ... View more

Please can you configure the originating call manager to send to the cube using UDP transport as well?   The TCP send error is with sending a 200 ok back to the originating call manager from the cube.   The receiving call manager is not getting an ACK from the cube and is resending its 200 ok.   thanks     ... View more

I've attached a script that will hopefully point you in the correct direction. If you really have a c887 - then consider replacing with one with VA in it's part number.   The script should work with both FTTC and ADSL. - VA chipset only. not sure how plusnet authenticates - check the info in the dialer section of the config.   Adam ... View more

Yeah, or maybe try udp.. ... View more

I don't like that the 200 OK from 65.11 isn't being responded to by the cube, at all. even if you had a codec problem, you'd expect some complaining for us to look at.   I'd investigate https://quickview.cloudapps.cisco.com/quickview/bug/CSCuu89938   and make sure you've not hit that.   Adam     ... View more

Try this   Log in to the phone web interface click admin click advanced click voice tab click ext1   Line enable = yes   scroll down to "Proxy and Registration" Proxy = sip.phonero.net Outbound Proxy = sip.phonero.net   Use OB Proxy In Dialog = yes Register = Yes Register Expires:  = 120 DNS-SRV Auto prefix = yes Use DNS-SRV = yes   Subscriber Information Display name = <put your sip username here> User ID  = <put your sip username here> Auth ID = <put your sip username here> Password <put your sip password here>   Click submit all changes   If this still fails 1. Ask your service provider 2. Read the manual 3. Configuration is not dis-similar to the old Linksys SPA   You might need to tweak your dial-plan for your region - again internet search for help. Here's mine in the UK: (*xx|999S0|[3469]11|0|00|0[1-3]xxxxxxxxxS0|07xxxxxxxxxS0|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.|+xxxxxxxxxxxx.)       ... View more

DTMF has a tendancy to fail on cisco ios devices if payload 96 is used by the service provider. This is because payload 96 is already used by a cisco fax service. To fix, move the fax service from 96 to something different   add this to your dial-peer rtp payload-type cisco-codec-fax-ind 124     just a guess... ... View more

There's a setting called "Feature Key Sync" on the ext tab under call feature settings. Its meant to synchronise setting like DND with the "server" where server might mean Broadsoft. not sure the mechanism - but you could try setting this one to yes to see if it does what you need it to. I'd be interested in the answer, so please let me know. Also- there's new firmware out (mid nov 2016) thanks Adam ... View more