Unable to create a voice recording

what is the CLI output w/ verbose 3

== Manager 'manager' logged on from 127.0.0.1

== Manager 'manager' logged off from 127.0.0.1

== Manager 'manager' logged on from 127.0.0.1

== Manager 'manager' logged off from 127.0.0.1

== Manager 'manager' logged on from 127.0.0.1

== Manager 'manager' logged off from 127.0.0.1

== Manager 'manager' logged on from 127.0.0.1

== Manager 'manager' logged off from 127.0.0.1

Chris

so you are saying that it doesn't even call the application?

Correct. Nothing gets called and the extension never rings.

what version of asterisk? AMI command Originate was broken in a few versions.

I can confirm it work with PBX Manager version 6.0.1.72 and asterisk version 1.4.24.1

I think I found the issue. Somehow I had the 1.4 version of manager.conf and I'm running 1.6. I copied over the correct manager.conf file( which includes originate in the write authorizations) and everything is working properly now.

Thanks for the help.

Chris

I have the same problem running PBX Manager 6.0.1.71 on asterisk 1.4.22.

What specifically needs to be in manager.conf to fix this? I tried adding 'friend' to the write field but to no avail..

Thanks,

Andy

for 1.4

[manager]

secret=somepassword

deny=0.0.0.0/0.0.0.0

permit=127.0.0.1/255.255.255.0

permit=69.64.100.0/255.255.255.192 ;;<-- other networks

permit=216.135.125.0/255.255.255.0 ;;<-- more subnets

read=system,call,log,verbose,command,agent,user

write=system,call,log,verbose,command,agent,user

Thanks Erik.

With that I can get it to ring an x-lite softphone, but for some reason it won't ring an Aastra phone (different extension with matched settings).

Once I click Start Recording, at CLI I get

-- Got SIP response 400 "Bad Request" back from 10.99.99.43

> Channel SIP/204-wtc-0925ab08 was never answered.

SIP debug (pub IP of PBX replaced with x):

Audio is at xxx.xxx.xxx.xxx port 14206

Adding codec 0x4 (ulaw) to SDP

Adding non-codec 0x1 (telephone-event) to SDP

Reliably Transmitting (NAT) to 10.99.99.43:5060:

INVITE sip:204-wtc@10.99.99.43:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK771eda10;rport

From: "" ;tag=as795f3c36

To:

Contact:

Call-ID: 74cb0e3c5a88abf62aa30c1b3530de49@xxx.xxx.xxx.xxx

CSeq: 102 INVITE

User-Agent: Asterisk PBX

Max-Forwards: 70

Date: Wed, 19 Aug 2009 15:00:22 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

Supported: replaces

Content-Type: application/sdp

Content-Length: 242

v=0

o=root 2913 2913 IN IP4 xxx.xxx.xxx.xxx

s=session

c=IN IP4 xxx.xxx.xxx.xxx

t=0 0

m=audio 14206 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=ptime:20

a=sendrecv

---

<--- SIP read from 10.99.99.43:5060 --->

SIP/2.0 400 Bad Request

Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK771eda10;rport

From: "" ;tag=as795f3c36

To: ;tag=1001001723

Call-ID: 74cb0e3c5a88abf62aa30c1b3530de49@xxx.xxx.xxx.xxx

CSeq: 102 INVITE

Server: Aastra 55i/2.4.1.37

Content-Type: text/plain

Content-Length: 23

Invalid header(s): From

<------------->

--- (9 headers 1 lines) ---

-- Got SIP response 400 "Bad Request" back from 10.99.99.43

Transmitting (NAT) to 10.99.99.43:5060:

ACK sip:204-wtc@10.99.99.43:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK771eda10;rport

From: "" ;tag=as795f3c36

To: ;tag=1001001723

Contact:

Call-ID: 74cb0e3c5a88abf62aa30c1b3530de49@xxx.xxx.xxx.xxx

CSeq: 102 ACK

User-Agent: Asterisk PBX

Max-Forwards: 70

Content-Length: 0

The phone otherwise successfully receives calls and can place calls without issues.

Thanks for your help

Andy

it sounds like your phone doesnt like the invite? The mechanism in play is no different than the click to call features inside the user portal for the contact directory. Can you confirm this too is not working?

Unable to duplicate with click to call, it works fine.

There is one difference in the notify. When doing the call recording, the beginning of the from header is blank:

From: "" (sip:@xxx.xxx.xxx.xxx);tag=as795f3c36

A click to call however has:

From: "Cisco Phone" (sip:275@xxx.xxx.xxx.xxx);tag=as3e35f0e9

Phone is Aastra 6755i running firmware 2.4.1.37. Also tried two older firmwares and still have the same problem. My guess is it doesn't like the blank From header. I am unable to duplicate with a Cisco 7960, as it seems to accept these invites fine just like the softphone client.

Thanks,

Andy

my ATA see's it as a 'blocked call' but rings the handset fine. I know it works on polycom phones and works on sofphones like you said.

It's probably trivial to fix since the Originate command allows you to set callerid, I dont think cisco phone is approriate either.

IMO the callerid on click-to-call should be set to the destination entry in the directory...

for recorded calls it should be CALLERID(all)="Asterisk"

I can't believe this is the first time this has come up... Personally I dont like snom and aastra phones, they look like 1980's and 1990's style phones where you pencil in info on white tear-out pieces of paper. However, there are a lot of people using them exclusively. If those phones refuse empty from headers then the Originate command must be modified to compensate as long as it doesnt interfere with other phone functionality (i cant see that it would).

I did a test originate from AMI

Action: Originate

Channel: DAHDI/5

Context: from-inside

Exten: 202

Priority: 1

Callerid: "Asterisk" <101>

displays correctly .. I'll see what I can do to get this added.

Thanks Erik. It is indeed surprising that this hasn't been reported before. Aastra phones account for ~80% of our IP phone sales that we package with hosted telephony solutions and one of the major problems we have with customizing other distros is the configuration that the client should be able to handle on their own, instead rely on us to make simple changes because of the complex nature of freepbx, elastix, and asterisk in general. I am very excited about thirdlane because this product is something that our tenants can actually manage with simple training.

I'm currently evaluating thirdlane-mte before I recommend purchasing a license to management, so I don't believe that I qualify for a fix for this, but I would like to know if it gets resolved soon as I plan to present my recommendations within the week.

Thanks again,

Andy

I have confirmed with Aastra that their entire range of IP phones enforces RFC2822 in sip header requirements and requires a valid "from" address.

"sip:@" is a malformed header with a null source and so violates this requirement. Other phones simply comply with RFC2822 without enforcement and so will accept these sip messages.

Anything I can adjust in the config to get around this until there is a fix?

Thanks,

Andy

nothign, webmin modules are encrypted so I do not have access to alter it (even though its a 1line fix)

Until then just use a free softphone with headset.

I have resolved this issue by adding callerid=Thirdlane (but can by anything) to the General section of sip.conf. This changes my invite headers called from the system:

From: "" (sip:@xxx.xxx.xxx.xxx)

to

From: "Thirdlane" (sip:Thirdlane@xxx.xxx.xxx.xxx)

This will work fine for me because I have complete control over the class 5 softswitch that the SIP trunk registers to. This forces me to create a SIP trunk for each individual tenant, with a matched separate binding per tenant on the softswitch, with the softswitch controlling CallerID for each tenant.

Many administrators of Thirdlane-mte are not SIP trunk providers and so it may be costly to purchase a SIP trunk for each tenant. Ideally you should be able to create a single SIP trunk with the SIP registrar allowing the PBX to control CallerID to satisfy all tenants that connect through it. However, by adding a value to callerid in the General section overrides per tenant CallerID.

Thanks,

Andy

you should _never_ send inbound sip calls through [general] .. that is anonymous guest access. I have personally warned about this at least 6 times in these forums. Please, when it happens, PayPal me some cash so I can drink some beer at your expense while laughing about it :)

this also does NOT mean you have to have a separate trunk per tenant... you simply need ONE trunk, one real trunk, one with some ip trust or authentication, where inbound calls are directed to context=from-outside. You merely do not declare callerid on this trunk so as to not to alter it. Your generic connections like random invites will still use the callerid declared in [general].

you should _never_ send inbound sip calls through [general] .. that is anonymous guest access. Gentlemen its only a matter of months before telemarketers start bulk SIP calling with bullshit recordings about crap costing your customers time, money, and patience. There is no 'do not call' registery for VOIP. If that call is delivered without touching the PSTN they can even send you bomb threats and not violate the specific telecom laws. I have personally warned about this at least 6 times in these forums. Please, when it happens, PayPal me some cash so I can drink some beer at your expense while laughing about it :)

this also does NOT mean you have to have a separate trunk per tenant... you simply need ONE trunk, one real trunk, one with some ip trust or authentication, where inbound calls are directed to context=from-outside. You merely do not declare callerid on this trunk so as to not to alter it. Your generic connections like random invites will still use the callerid declared in [general].

Thanks Erik. I didn't notice that context=from-outside was specified in General. It looks like it is the default setting on a fresh install.

Cheers,

Andy

set allowguest=no under [general] to prevent receiving unauthorized calls. then create a trunk for your calls to enter/leave. If your inbound calls do not send proxy-authentication then use insecure=port,invite and set the hostname (also change type=peer) so that inbound calls match based on ip (can only have 1 peer per ip).

I'm having the same problem as chris, can some one please post the correct manager.conf file for 1.6 so I can compare.

Thanks,
Brandon

I am having the same problem as chris, mine also does not call the application. Where did he get the manager.conf file for 1.6 and how do i tell what version mine is from. I am running asterisk 1.6.0.6 and thirdlane ST 6.0.1.79 I am also not able to access the manager interface with the following error.

Asterisk 1.1
-----------------------
Response: Error
Message: Authentication failed
ActionID: 88E81BF1-9EC1-2D69-478B-969D1EB56BD2
Fault: Login
-----------------------

I tried to permit the ip address of my local machine but i have a feeling i'm way off base with that. Here is a copy of my manager.conf file

[general]
enabled=yes
port=5038
bindaddr=0.0.0.0
writetimeout=200

[internal]
secret=insecure
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
read=system,call,log,verbose,command,agent,user
write=system,call,log,verbose,command,agent,user

[manager]
secret=insecure
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
permit=192.168.1.0/255.255.255.0
read=system,call,log,verbose,command,agent,user
write=system,call,log,verbose,command,agent,user

I am new to all of this so this may not be related but it is the only other problem i'm having and that is that in my CLI verbose 3 I continually get a warning about failing to spawn an mp3 player.

Thanks in advance for any help.

[manager]
writetimeout=200 ;;=Asterisk-1.6
secret=insecure
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
permit=10.0.0.0/255.0.0.0
permit=169.254.0.0/255.255.0.0

read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan
write = system,call,agent,user,config,command,reporting,originate

asterisk 1.6 added in a couple read/write permissions, once I added the full read/write permissions into the sip.conf it worked just fine.

I added the read write permissions to the manager.conf and that made my voice recordings show up under recordings but will still not let me record. I do not see where to put them in sip.conf can you give me an example.