As recent as 2008 “Asterisk 1.4 is feature frozen” if that is the case
how come now CallingToken support is added? I don’t really know what
this is but all I know is:

1) Callingtoken adds new options to the config files
2) Callingtoken is some new protocol in IAX?
3) Upgrading asterisk 1.4 breaks previous IAX connections.

So why was this added? I have 1 machine that is set not to log these
messages on the console and am pulling my hair out after upgrading
Asterisk 1.4 to a new release. It is not anything I would look into
normally since “Asterisk 1.4 is feature frozen” so why would I look
to troubleshoot a feature that isn’t supposed to be there?

I have 2 FXO channels from which I want to route incoming calls to
different contexts in extensions.conf. I edited the context entries in
dahdi-channels.conf and created matching entries in extensions.conf.
One channel is routed to the new context as I want, but the other
channel is stuck going to the default “from-pstn” context no matter what
I do.

Can anyone see what I’ve missed?

From dahdi-channels.conf:
;;; line=”3 WCTDM/4/2 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn-3
channel => 3
callerid=
group=
context=default

;;; line=”4 WCTDM/4/3 FXSKS”
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn-4
channel => 4
callerid=
group=
context=default

From extensions.conf:
[from-pstn]
exten => s,1,Wait(1)
; exten => s,n,Answer
exten => s,n,Dial(SIP/1000)
exten => s,n,Hangup

[from-pstn-3]
exten => s,1,Wait(1)
;exten => s,n,Answer
exten => s,n,Dial(SIP/1000)
exten => s,n,Hangup

[from-pstn-4]
exten => s,1,Wait(1)
exten => s,n,Answer
exten => s,n,Dial(SIP/1000)
exten => s,n,Voicemail(1000,u)
exten => s,n,Hangup

From the debug output:
chan_dahdi.c: — Starting simple switch on ‘DAHDI/4-1′
pbx.c: — Executing [s@from-pstn-4:1] Wait(“DAHDI/4-1″, “1″) in new
stack
pbx.c: — Executing [s@from-pstn-4:2] Answer(“DAHDI/4-1″, “”) in new
stack
pbx.c: — Executing [s@from-pstn-4:3] Dial(“DAHDI/4-1″, “SIP/1000″)
in new stack
netsock.c: == Using SIP RTP TOS bits 184
netsock.c: == Using SIP RTP CoS mark 5
app_dial.c: — Called 1000
app_dial.c: — SIP/1000-00000012 is ringing
pbx.c: == Spawn extension (from-pstn-4, s, 3) exited non-zero on
‘DAHDI/4-1′
chan_dahdi.c: — Hungup ‘DAHDI/4-1′
chan_dahdi.c: — Starting simple switch on ‘DAHDI/4-1′
pbx.c: — Executing [s@from-pstn-4:1] Wait(“DAHDI/4-1″, “1″) in new
stack
pbx.c: — Executing [s@from-pstn-4:2] Answer(“DAHDI/4-1″, “”) in new
stack
pbx.c: — Executing [s@from-pstn-4:3] Dial(“DAHDI/4-1″, “SIP/1000″)
in new stack
netsock.c: == Using SIP RTP TOS bits 184
netsock.c: == Using SIP RTP CoS mark 5
app_dial.c: — Called 1000
app_dial.c: — SIP/1000-00000013 is ringing
pbx.c: == Spawn extension (from-pstn-4, s, 3) exited non-zero on
‘DAHDI/4-1′
chan_dahdi.c: — Hungup ‘DAHDI/4-1′
chan_dahdi.c: — Starting simple switch on ‘DAHDI/3-1′
pbx.c: — Executing [s@from-pstn:1] Wait(“DAHDI/3-1″, “1″) in new stack
pbx.c: — Executing [s@from-pstn:2] Dial(“DAHDI/3-1″, “SIP/1000″) in
new stack
netsock.c: == Using SIP RTP TOS bits 184
netsock.c: == Using SIP RTP CoS mark 5
app_dial.c: — Called 1000
app_dial.c: — SIP/1000-00000014 is ringing
pbx.c: == Spawn extension (from-pstn, s, 2) exited non-zero on ‘DAHDI/3-1′
chan_dahdi.c: — Hungup ‘DAHDI/3-1′

I want to be able to allow a caller to dial a ddi, system to verify
identity etc (this is all done)

I then want them to sit listening to music, until an event happens.
When this (external) event happens, I want to play a certain file to
the caller, using playback (so that they have ff / rw etc), and when
finished, go back to the music.

1) I thought of redirecting to an extension that played the file, and
then jump back to the original dialplan entry to start again. However,
If I want to redirect, then this external event would need to know
their channel.

2) I thought of a meetme / conference, but then they would not be able
to control the playback of the file, right ?

Anyone got any other thoughts ?

TIA

Julian

Hi all,

We’re trying to make voice and SMS apps easier and more common. We solved
one part of the problem with pay-as-you-go cloud-scale Asterisk hosting, and
now we’re trying to make the app setup easier. With a few exceptions, setup
docs are too rare, and they depend on knowing too much about Asterisk. That
complexity deters businesses from integrating phone calls into their
products.

So we just put up $250 bounties for writing simple setup docs for some
Asterisk apps: Web-MeetMe, BigBlueButton, MonAst, AsterCRM, Queue-Tip, Flash
Operator Panel, and Asterisk PHP Event Monitor.

Basically, install one of these apps interoperating with Asterisk on
Cloudvox, document what you did so others can do it too, get $250. Here’s
details:

http://blog.cloudvox.com/post/1022356872/install-an-open-source-asterisk-phone-app-get-250
http://twitter.com/cloudvox/status/22312112543

Our goal is to make these apps deployable without needing to know much about
voice infrastructure, and hopefully that will encourage others to add phone
calls, SMS, and video to their services.

Cheers,

Troy

Use sox to downsample to 8khz (and 1 chan), and the problems should go away. While you are at it, you could use sox to convert to the target format in a single operation.

The scripts that Digium uses to take Allison’s voice prompts (at 48khz) to the different formats, convert things to slin (raw) as a central format, but in my experience, the fewer steps the better. But I doubt that anyone could detect the difference in the end result.

Here’s what I do with CD-qual sounds to turn them into the common Asterisk formats:

Assume $i is the name of the .wav file you want to convert:

I’m ignoring the siren & g729 formats; use asterisk for those in like format, depending on your asterisk version and codecs. Allison normalizes the volume of sounds she distributes; use the -v 0.7 to bring the volume down a bit to the standard, and your sounds won’t stick out against rest of Allison’s existing recordings in Asterisk. Digium uses a filter program to ‘heighten’ the sounds a little; That’s the main reason, I think, that they use the .raw format as an in-between. I’ve been skipping this step, as it doesn’t seem critical, in which case the direct conversion is probably preferable.

I suggest, that if you are converting sounds for Asterisk’s sake, that you convert to all the possible formats. Disk space is cheap, and you’ll squeeze a little extra performance out of Asterisk by allowing it to pick the ‘best’ format. Dahdi type interfaces would prefer the ulaw/alaw formats; High-def phones like Snom (and appropriate Polycoms, etc) could use the g722. Ulaw and gsm transcodings are cheap, but no transcoding is cheaper still.

If you load “res_convert.so”, you will have a CLI command “file convert …”.
Usage: file convert
Convert from file_in to file_out. If an absolute path is not given, the default Asterisk sounds directory will be used.

Example:
file convert tt-weasels.gsm tt-weasels.ulaw

or,

asterisk -rx “file convert /home/user/tt-weasels.gsm /home/user/tt-weasels.g729″