Got a problem with a UC540. Call forwarding does not work to external numbers. That is both CFwdAll set from handsets, call forward on busy set from CCA and manual transfers to external numbers.
You just get slow busy.
All calls are via SIP.
I've attached a cut down running-config.
Thanks for any advice,
I take it you can dial in and out OK, just call-forward that's failing, right? I've seen this a few times.
You seem to be going through a 3rd party router for Internet connectivity -
ip route 0.0.0.0 0.0.0.0 10.149.52.1
What is this device and what is the configuration? You may be running into a weird NAT problem.
Can you gather the SIP debugs from CLI:-
debug ccsip mess
Make your calls and post the results, I'm sure this would give enough info for help.
I had a the same problem with a system. I will check later if I find some documentation about it.
But until then, please remove all you passwords in your file! On a short look I've seen commands with passwords for SIP and telephony-service.
*please rate helpful posts
hhmm, not really seeing enough info there. Can you possibly explain the exact call flow, and also "debug ccapi inout" and "dubug voice dialpeer".
When I've seen this in the past I worked with the SIP trunk provider to resolve, can you try
And remove again if it does not help! (I have tyhi in one config for some reason but I cannot recall whicg bug it fixed)
The suggestion that Pierre mentioned tells the UC to send the number that the caller uses as the calling number rather then the number that actually forwards the call.
Adam, when u enable the CFA on a internal phone, and call the phone from another extension, does it work?
Did u manage to get some debugs as suggested? debug ccsip mess is a good one. U could try to make a PCAP aswell
on the UC. If u would like to know how, i should have a config example somewhere.
Does the provider support u sending an unknown number (caller id when forwarded) over the SIP trunk?
We do need some more information!
I have taken a look at your trace (didnt see it before)
You are getting a disconnect cause 47, this is often a codec mismatch cause, or a problem with your transcoding on the UC.
Could u try to get a PCAP of the call? Or try to make one and see if u are indeed getting a codec mismatch.
Then hardcode one codec under voice class codec x and see if this helps!
1. Define a traffic-export profile with bidirectional traffic included. Also, it is possible to apply ACLs to filter the capture, but if no ACL is defined, all traffic will be captured. Mode 'capture' means traffic will be captured in the buffer located in router's RAM.
ip traffic-export profile PCAP mode capture
2. Apply the traffic-export profile to the interface which traffic will be intercepted. We'll define buffer of 20MB for our purposes:
ip traffic-export apply PCAP size 20000000
3. Start capturing from PRIV EXEC mode:
traffic-export interface fa0/0 start
4. Stop capturing from PRIV EXEC mode:
traffic-export interface fa0/0 stop
5. Copy capture buffer to flash:, disk:, tftp:, http:, ftp: etcÖ We'll use flash: for our example. Buffer contents will be stored in file buffer.pcap:
traffic-export interface fa0/0 copy flash:/fa0.pcap
To stop all
no ip traffic-export profile PCAP mode capture
no ip traffic-export apply PCAP size 20000000