星号起源不起作用

Question

I am trying to make vtiger work with asterisk 1.6 (freepbx server). I have managed to get to the point where I can connect to the asterisk manager interface (AMI) and write to it. But for some weird reason, the originate would not work. I am using -

Action: Originate
Channel: SIP/2000
Exten: 1000
Context: from-internal
Priority: 1
Callerid: 2000
Async: yes 

I tried reading the responses from AMI after making a direct call and it always had a random number after the channel. For example -

Event: Dial
Privilege: call,all
SubEvent: Begin
Channel: SIP/1000-0000000c
Destination: SIP/2000-0000000d
CallerIDNum: 1000
CallerIDName: 1000
UniqueID: 1359790601.12
DestUniqueID: 1359790601.13
Dialstring: 2000

Can this be an issue or am I missing anything here? Any pointers would be most helpful. Would be happy to provide any details.

Answer 1

Random number added,becuase can be more then one channel to same extension.

Cordinly to info you provided it do call. No way determine using this info why it "not working" for you, sorry.

Use asterisk -rvvv

to check what happens on asterisk. Also will be nice read some book like "Aterisk the future of telephony"(or hire consultant able determine what you dooing wrong).

Answer 2

I managed to fix the issue, so here is how the debugging went -

1. started asterisk CLI using asterisk -rvvv
2. used a CLI originate command

   channel originate SIP/1000 extension 2000@from-internal

3. step 2 showed an error on the extension being busy (error 486 to be specific).
4. googled error to find out that the extension 1000 is being used by a hard phone and that can cause issues

5. changed the manager extension to 2000 in manager.conf and tried making the call using

   channel originate SIP/2000 extension 1000@from-internal

6. step 5 worked, but calls from PHP still failed. added debugging to find that the AMI was returning a permission denied

7. found out that from 1.6 onwards you need to have originate in the manager.conf read/write options

Now it works perfectly fine. Hope this helps someone, though I think this case might be a very personalized issue.