Re: [asterisk-dev] DTMF detection and generation code
Vahan Yerkanian wrote: Steve Underwood wrote: With most cellular base stations each press of the buttons on the phone produces a fixed length DTMF pulse, with a fixed silence following it. If you press keys in quick succession, they are buffered up, and played out as tones at the pace the base station sees fit. Typically they make the tones very long, for some reason. 0.5 seconds in many cases. I think your application sounds broken by design. I've been through this before, trying to build things which require rhythmic input. It just doesn't work, unless your application is limited to plain old analogue land line phones. DTMF buffer is another useful thing - currently digits sent too fast are guaranteed to be skipped. Ironically, I never get a double or skipped digits from cellular networks - these send DTMFs with lng durations as the developers have accounted for lossy nature of the cellular technology. The lossy nature of cellular networks has no impact on DTMF. The phones do not generate DTMF. The base stations do. The phones merely send messages saying user pressed one, user pressed five, etc. and they don't tell the base station how long it was pressed for. The base station generates the DTMF tone in a non-lossy environment. Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Command Syntax -- weird?
Peter Beckman wrote: The fact that flags to voicemail (though you point out that his is changing - sweet!) are part of the mailbox# string is confusing when the Dial flags are a comma delimited part of the parameters. Actually, the options string to Voicemail was moved to the end even before Asterisk 1.2 was released five months ago. In fact, this change was made on April 13th, 2005 - revision 5461 (we're currently on revision 22230). That was over one year ago! So, perhaps before you make posts to the development list pointing out problems, you should check to see that your statements are still accurate, and not more than a year out of date. Russell ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Command Syntax -- weird?
On Sun, 2006-04-23 at 19:25 -0400, Peter Beckman wrote: Change always breaks things. The question is when does breaking things now make things better in the future? Sure, changing around a few strange function syntaxes won't make much of a difference. But I do think that consistency is worth breaking backward compatibility for. Please Read http://www.catb.org/jargon/html/F/flag-day.html -- Steven [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Command Syntax -- weird?
On Sunday 23 April 2006 18:46, Peter Beckman wrote:
On Sat, 22 Apr 2006, Tilghman Lesher wrote:
It must add a lot of code to parse out all of that stuff, and
having an inconsistent method of calling functions make both
documentation confusing and the user/admin confused. It makes
Asterisk seem cobbled together, and though it may be, the
disconnect between a unified code front seems like more of a
hack, rather than the production-ready and profesional front I
think Asterisk really has.
I don't see how this has anything to do with an inconsistent
method of calling applications (again, these are applications,
not functions; functions are something different). The method of
calling applications is entirely consistent. The order of the
arguments to the application is what you appear to have trouble
understanding.
Sorry, I'm new to Asterisk, so my name-calling :-) seems to be
inaccurate.
I didn't mean internally to Asterisk, I meant as an end-user of
Asterisk. The fact that required parameters passed to an
application sometimes come at the beginning
sometimes in the middle,
What application does this?
and sometimes at the end seems to be inconsistent. The
Labels are pretty much the only construct which are parsed right
to left, and they are always done in a way that is clear and
unambiguous.
fact that flags to voicemail (though you point out that his is
changing - sweet!) are part of the mailbox# string is confusing
when the Dial flags are a comma delimited part of the parameters.
That's what I meant, though I hope I've explained it better here.
:-)
The Dial flags are NOT a comma-delimited list. In fact, none of the
applications currently use a comma to delimit arguments. They instead
use a vertical-bar-delimited list (except for things like conditionals
which use ternary delimiters ('?' and ':')).
Not even to unify the codebase?
Labels are already consistent across the codebase. What you're
having trouble with is understanding that labels are parsed
right-to-left. This isn't an inconsistency -- it's simply
different from how other types of arguments are parsed.
I can understand right-to-left, but then wouldn't all required
parameter(s) be the last parameter(s) passed to the application,
and the optional parameters be listed first? That's not the case
with Dial(), right?
Dial is entirely consistent with other applications, in that arguments
are parsed left to right. Labels are parsed right-to-left, but they
are always present in a location which disambiguates the possibility
of other arguments. For example, GotoIf is the prime example of where
a label is used:
GotoIf(1?34:s,1)
GotoIf is first parsed using the ternary operators ('?' and ':').
Once this is done, the only things left in the second and third
pieces are labels. There are no other arguments possible in these
arguments, so parsing this construct right-to-left is not confusing.
I think Asterisk is a great tool, and very powerful, but without
good, solid, accurate and up-to-date online web-based
documentation, it is a tool for the tinkerer, not the masses.
I think you've just made an argument for why the coders behind
the project should boot the documenters. :-) I'm not saying we
should do that, but Asterisk has always been for the tinkerer; it
will never be for the masses. This is the concept that a lot of
people seem to have trouble understanding -- the community of
developers that support an open source project do so for their
mutual benefit, not to create a super-polished application that
the typical computer user can use.
That's disappointing. The voip-info wiki seems to be a cry for
good documentation. The docs there are inconsistent, usually out
of date, and are difficult at times to understand. But that's the
best documentation Asterisk has -- documentation written by a bunch
of people, developers and users, who benefit enough from Asterisk
to be willing to document this software for free, anonymously.
Which docs, specifically, are out of date? I'll admit that the Wiki
tends to be disorganized, but I rarely find documentation which is
out of date.
It seems a lot of hard work goes into Asterisk by its developers.
Many businesses, including mine, rely on Asterisk every day. The
VoIP world is growing at a phenomenal rate, and Asterisk seems like
the perfect glue to bring it all together, for businesses,
tinkerers, and for the geeky homeowner.
Exactly. And this time, you left out the masses, which was my point.
Asterisk will always be for a self-selected few who wish for one
reason or another to run a PBX. This has never included the general
populace, and I doubt it ever will.
I think Asterisk deserves to have great, polished documentation,
and I think the effort to make Asterisk a super-polished
application is very little. It seems to be pretty well polished
already -- it sure hasn't crashed on
Re: [asterisk-dev] Command Syntax -- weird?
On Sun, 23 Apr 2006, Russell Bryant wrote: Peter Beckman wrote: The fact that flags to voicemail (though you point out that his is changing - sweet!) are part of the mailbox# string is confusing when the Dial flags are a comma delimited part of the parameters. Actually, the options string to Voicemail was moved to the end even before Asterisk 1.2 was released five months ago. In fact, this change was made on April 13th, 2005 - revision 5461 (we're currently on revision 22230). That was over one year ago! So, perhaps before you make posts to the development list pointing out problems, you should check to see that your statements are still accurate, and not more than a year out of date. I normally would! Where's that documentation? I found this: http://www.asterisk.org/doxygen/app__voicemail_8c.html But I can't really find the options for Voicemail in that 1MB file. By doing a show application voicemail and searching for This application allows I did find it in line 338 of app_voicemail.c. And I agree, it clearly points out what the options string to Voicemail is. I believe most people who do not develop Asterisk and who don't know about the show application xxx command (and while they should, they don't) go to voip-info.org wiki, which tends to be wildly inaccurate. Clearly my source, voip-info.org, for the flags in Voicemail is incorrectly documented. All I want to do is take this documentation: -= Info about application 'VoiceMail' =- [Synopsis] Leave a Voicemail message [Description] VoiceMail([EMAIL PROTECTED][EMAIL PROTECTED]|options]): This application allows the calling party to leave a message for the specified list of mailboxes. When multiple mailboxes are specified, the greeting will be taken from the first mailbox specified. Dialplan execution will stop if the specified mailbox does not exist. The Voicemail application will exit if any of the following DTMF digits are received: 0 - Jump to the 'o' extension in the current dialplan context. * - Jump to the 'a' extension in the current dialplan context. This application will set the following channel variable upon completion: VMSTATUS - This indicates the status of the execution of the VoiceMail application. The possible values are: SUCCESS | USEREXIT | FAILED Options: b- Play the 'busy' greeting to the calling party. g(#) - Use the specified amount of gain when recording the voicemail message. The units are whole-number decibels (dB). s- Skip the playback of instructions for leaving a message to the calling party. u- Play the 'unavailable greeting. j- Jump to priority n+101 if the mailbox is not found or some other error occurs. And turn it into this: http://mph.gotdns.com:82/manual/en/function.voicemail.php There are some examples, a bit more enumeration about the function, notes about the mutual-exclusivity of the b and u flags, the (potentially inaccurate) note about the arrival of the j and g flags, the change in version about the flags, and once I get it working, an asterisk code-based version information about when that application showed up in Asterisk. Can you see my vision? What's there is good, but I think it can be better. Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] DTMF detection and generation code
I also thought the same until found that if I press buttons on my Treo650 too fast, DTMF tones did not get recognized by my Cisco IVR. I think there are different behaviours with different phones. On 24 April 2006 04:52, Steve Underwood wrote: Vahan Yerkanian wrote: Steve Underwood wrote: With most cellular base stations each press of the buttons on the phone produces a fixed length DTMF pulse, with a fixed silence following it. If you press keys in quick succession, they are buffered up, and played out as tones at the pace the base station sees fit. Typically they make the tones very long, for some reason. 0.5 seconds in many cases. I think your application sounds broken by design. I've been through this before, trying to build things which require rhythmic input. It just doesn't work, unless your application is limited to plain old analogue land line phones. DTMF buffer is another useful thing - currently digits sent too fast are guaranteed to be skipped. Ironically, I never get a double or skipped digits from cellular networks - these send DTMFs with lng durations as the developers have accounted for lossy nature of the cellular technology. The lossy nature of cellular networks has no impact on DTMF. The phones do not generate DTMF. The base stations do. The phones merely send messages saying user pressed one, user pressed five, etc. and they don't tell the base station how long it was pressed for. The base station generates the DTMF tone in a non-lossy environment. Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Re: DTMF detection and generation code
Hello-- I see this discussion about DTMF in Asterisk, and at the danger of forking the discussion, I dare here to present a problem I've been having with DTMF... I have an FXO Zap card (X100P) in my system, and I've got the privacy manager being run on incoming calls. The county's school system, trying to lower telecommunications costs, have gotten themselves T1's with no callerID. And on their side, everything is VOIP. They consistently fail the privacy manager when calling me! They simply cannot use DTMF to talk to my system. My system simply cannot recognize their tones. I've got the 'relaxedDTMF ' option turned on, BTW. So why is just this one source such a problem, when everyone else has no problems? I ask them to hit a key when I talk to them, and I can hear the tones generated. murf ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
