turn on sip debug. you'll probably find a reason for the call to fail instead of beginning to transfer sound.
If, for instance, your phone insists on g729, but the server doesn't have g729 installed ... well, that ain't workin'.
process:
Server "invites" phone to a call
Phone receives invite and rings the user interface
Phone sends "ringing!" back to the server
this is how it sits while ringing ... eventually, you pick up the phone.
Phone sends Answer! and here's the codecs I can use to server.
Server sends "here's the codecs I can use for audio" to the phone.
Phone picks a codec ... IF they match. If there is no overlap in the phone vs server codecs, they can't begin audio. Then they both agree this ain't workin' and terminate the call.
But this all happens in SIP, unrelated to the "extension dialplan". All the asterisk CLI shows is the extenson dialplan logging. So if you show SIP DEBUGging, you'll see that background handshake, too.
But I warn you: It's confusing and there's A FREAKIN LOT of packets back and forth. Do not have anthing else happening on the server. It would be best if you even turned off all other workstations and shut down the carriers (change yes to no) for a couple minutes before your attempt. That may make it easier for you to see and reason these packets. Note, of course, that all you need is the "termination/rejection" reason. The rest is just babble.