|
uniqs
12 |
|
 |
|
| |
to Stewart
Re: PAP2T - firmware mod possible for DTMF Strict Hold Off?Thanks Stewart for the info, I do have both lines of my PAP2T in use and I'm having problems with Google Voice voicemail on my line connected to Voxox, it only seems to work with DTMF set to AVT, but I get bad DTMF talkoff when it is set this way. I also had this same problem with Magicjack voicemail when I was running it on my PAP2T, but I haven't been able to do that since they changed the algorithm for the passwords a few months back.
I opened the 5.1.6 firmware in a hex editor and saw 4 different entries for "DTMF Tx Strict Hold off Time" although I don't want to just start changing things without knowing exactly what the values are since I don't want to risk bricking my adapter.
DogFace05 (or anyone else who knows their way around Linksys firmware) - if you are reading this and have any suggestions on how to edit the firmware please let me know. | |
1 edit |
said by CartDude:Thanks Stewart for the info, I do have both lines of my PAP2T in use and I'm having problems with Google Voice voicemail on my line connected to Voxox, it only seems to work with DTMF set to AVT, but I get bad DTMF talkoff when it is set this way. I also had this same problem with Magicjack voicemail when I was running it on my PAP2T, but I haven't been able to do that since they changed the algorithm for the passwords a few months back.
I opened the 5.1.6 firmware in a hex editor and saw 4 different entries for "DTMF Tx Strict Hold off Time" although I don't want to just start changing things without knowing exactly what the values are since I don't want to risk bricking my adapter.
DogFace05 (or anyone else who knows their way around Linksys firmware) - if you are reading this and have any suggestions on how to edit the firmware please let me know. You didn't just open the firmware in a text editor, as all you'd have seen, would be gibberish. The PAP2T firmware is gzip compressed, not just once, but twice. To have seen the textual strings you mention, you must have run the firmware through a program that decompressed and extracted its component code and data segments. Someone wrote such a program (independently of me) a few years ago, and I assume it's what you've used. If you modify any of the segments, you then have to compress and repackage everything back into a valid image. This is in and of itself not a trivial task. To make matters more difficult, the overall image is protected with two digests. One of the digests' algorithms is publicly known; the second is not and was added to prevent people from hacking the firmware when the first became known. AFAIK, I'm the only person in the world to have reverse engineered how to calculate the latter, and the only one to have ever succeeded at patching their firmware into anything usable. But even if you could repackage the firmware back into a valid image, you have to find the right code to patch. Modifying text isn't going to do anything for you. You have to disassemble the code segments and find the actual instructions that initialize the SLIC chips. There are over 170,000 lines of disassembled code to sift through. Unfortunately, they don't come with any kind of comments to help you find your way. And assembly language instructions don't give you any clues into what you're looking at, unless you already know what you're looking at. It is made even worse by the fact that there's no meaningful public documentation available to make sense of the ESS chipset at the heart of the PAP2T. If you're not familiar with the internals of the hardware and firmware, you'd be looking at potentially several years of full time dedication just trying to make sense of the code and its layout, and searching for where to patch. Even for me, after having dedicated (read "wasted") more than 20,000 hours reverse engineering and developing solutions for Linksys ATAs, and as a result become more familiar with their internals than anyone else on the planet, bar the designers themselves (not something I'm particularly proud of--there are far better things to invest one's time developing expertise in), it could take me anywhere from a few days (best case, if I get really lucky and happen to guess right to start with) up to several months of searching full time. And then, even if I found the location, patched the code, and created a new loadable image, I could not make it available to you without violating federal law. The best I could do, would be to make a patching program that would automatically decompress, extract, patch, and then repackage the firmware when fed to it. You would then yourself run that program on your legally obtained copy of the firmware. Creating such a program, though, would in and of itself involve a substantial amount of work that I just don't have the means nor time to afford dedicating. All that said, I think you're looking at the totally wrong approach. If I understood you right, you're hearing the talk-off at your end; it's not the remote end hearing it. Right? If that's the case, you're looking at a problem that has absolutely nothing to do with your PAP2T, as the talk-off is coming from the remote end. Your ATA does not listen for inbound DTMF from remote ends; it only listens for DTMF from your local phone. If it is configured to send digits out-of-band, and misdetects voice as DTMF, it is only the remote end that will hear it, not you. The PAP2T normally regenerates received out-of-band DTMF indications and plays them back to you. However, when set to in-band, it may mask/ignore those remote indications, and not play them back to you, but it isn't the PAP2T causing those false indications. The root of the problem is at the remote end, not yours. | | | |
If the OP is correct and the parameter name string is present, do you think it's possible/likely that it can be set via a config file, even though it does not appear in the web UI. There are certainly other parameters like that, e.g. Protect IVR FactoryReset.
If you are correct and it's inbound talk-off, setting DTMF Playback Level way down should make it much less annoying.
IMO the ATA makers have done at best a mediocre job with respect to talk-off. Fewer than 1 in 10,000 users need inbound DTMF on outgoing calls and it should be disabled by default. Inbound DTMF on incoming calls is useful for a small percentage of users, e.g. remote access to an answering machine. The others should be able to turn it off if it causes trouble. Outbound, if codec is G.711, IMO the ATA should not send AVT if no DTMF has been received for 30 seconds. This would cause only a tiny degradation in DTMF reliability but would reduce talk-off by at least 90%. | | | |
Thanks for the detailed info DogFace05. What I did is open the pap2t-5-1-6-LS-spc-win32-i386.exe file in a hex editor and I searched for the text string "DTMF Tx Strict Hold off Time" and I see 4 entries like this:
DTMF Tx Strict Hold off Time[1].90
DTMF Tx Strict Hold off Time[2].90
DTMF Tx Strict Hold off Time[3].90
DTMF Tx Strict Hold off Time[4].90
I don't know if the "90" is the default value or not, but based on the release notes I saw on another website it says the Hold off Time is variable based on the Tx Method, so I would think changing the value to anything wouldn't have any effect. I'm an applications programmer by day, but I don't even want to attempt to change this and end up with a paper weight.
The problem I have with talkoff is on the other person's end. I don't hear it myself but the people I call all tell me my phone beeps like crazy. I guess my voice just has that frequency that makes it more prone than others.
I just signed up with a new provider and their voicemail system doesn't work with Inband DTMF either which is very frustrating. I'm able to check it remotely using a different phone, but that isn't very ideal for me.
I guess I'll have to look into getting the SPA2102 after all, it sounds like that is the only way I can change the "DTMF Tx Strict Hold off Time" value and avoid talkoff issues. | |  brg
Premium Member
join:2001-01-03
Chicago, IL |
to DogFace056
said by DogFace056:Even for me, after having dedicated (read "wasted") more than 20,000 hours reverse engineering and developing solutions for Linksys ATAs...
Wow that's 10 years worth of of a full-time-job-equivalent: 8 hours per day for 5 days a week (= 40 hours), times 50 weeks per year (= 2000 hours assuming [only] 2 weeks vacation) for 10 years straight (= 20,000 hours). What did you do for your day job?  | |
1 edit |
to Stewart
said by Stewart:If the OP is correct and the parameter name string is present, do you think it's possible/likely that it can be set via a config file, even though it does not appear in the web UI. There are certainly other parameters like that, e.g. Protect IVR FactoryReset. I checked the 5.1.6 firmware's table of supported parameters (one of the many tools I've developed over the years is one that decompresses the firmware, automatically searches for this table using heuristic means, and prints it out), and "DTMF Tx Strict Hold off Time" is not at all supported by either web or provisioning interfaces. If you are correct and it's inbound talk-off, setting DTMF Playback Level way down should make it much less annoying. My interpretation was wrong, and it turned out to be outbound talk-off. This is why it's important that people be specific, as it makes the problem an entirely different one. IMO the ATA makers have done at best a mediocre job with respect to talk-off. Fewer than 1 in 10,000 users need inbound DTMF on outgoing calls and it should be disabled by default. Inbound DTMF on incoming calls is useful for a small percentage of users, e.g. remote access to an answering machine. The others should be able to turn it off if it causes trouble. DTMF talk-off is a complex problem with no ideal solution. I wrote a post on the subject some time ago, which you may want to refer to. Saying that "fewer than 1 in 10,000 users need inbound DTMF" is a very subjective statement probably based on your own needs. There are all kinds of users with different needs out there, and accommodating them all is a challenge, especially when selecting default settings. The defaults that work for one group, are bound to break it for another. In particular, disabling inbound DTMF on outbound calls by default, would not work for ATAs used for interfacing with an alarm monitoring service. I do agree with you that users should have the option of turning on or off inbound DTMF. There is the setting "DTMF Playback Level" that can be turned down (not sure what its lower limit is). Looking at the table of parameter for PAP2T version 5.1.6, there's also a couple of other settings that may be useful: "DTMF Process AVT" and "DTMF Process INFO". I haven't investigated what these settings really do, nor what direction they affect, but I suspect that they are meant for turning on/off inbound out-of-band DTMF. Outbound, if codec is G.711, IMO the ATA should not send AVT if no DTMF has been received for 30 seconds. This would cause only a tiny degradation in DTMF reliability but would reduce talk-off by at least 90%. It would also break DISA systems that allow the DISA user to end their current call (by dialing a certain digit) and make new calls without having to hang up and call back in. The best solution is to abandon ATAs altogether and use all-digital phones, but even then it's not guaranteed, depending on what kind of out-of-band DTMF notification a user's VoIP provider may or may not support, if any. | | DogFace056
1 edit |
to CartDude
said by CartDude:Thanks for the detailed info DogFace05. What I did is open the pap2t-5-1-6-LS-spc-win32-i386.exe file in a hex editor and I searched for the text string "DTMF Tx Strict Hold off Time" and I see 4 entries like this:
DTMF Tx Strict Hold off Time[1].90
DTMF Tx Strict Hold off Time[2].90
DTMF Tx Strict Hold off Time[3].90
DTMF Tx Strict Hold off Time[4].90
I don't know if the "90" is the default value or not, but based on the release notes I saw on another website it says the Hold off Time is variable based on the Tx Method, so I would think changing the value to anything wouldn't have any effect. I'm an applications programmer by day, but I don't even want to attempt to change this and end up with a paper weight. That explains it. What you looked at was the profile compiler, not the firmware. The setting is there because this compiler is actually based on the same source code used to generate the corresponding profile compiler for other Linksys adapters, including the SPA2102, which does have that setting. You can try compiling a .cfg file with it, with that parameter set to any value you like (if it will accept it), but it won't have any effect when loaded/provisioned into the PAP2T, which doesn't support the setting (at least not in version 5.1.6). It won't produce a paper weight either, so there's no harm in trying it if you like. The problem I have with talkoff is on the other person's end. I don't hear it myself but the people I call all tell me my phone beeps like crazy. I guess my voice just has that frequency that makes it more prone than others. Your problem may actually be that your phone is generating too loud speech/DTMF. Overloading the A-to-D converter results in clipping distortion, which contains a great deal of overtones. Such overtones are far more likely to cause false DTMF detection (talk-off) than your normal voice. Clipping can also wreak havoc with adaptive echo cancelers. You can try adjusting/reducing the "FXS Port Input Gain" to ensure there's no clipping, and see if it improves the talk-off. This may also help remote systems work more reliably when your ATA is set to in-band DTMF. I just signed up with a new provider and their voicemail system doesn't work with Inband DTMF either which is very frustrating. I'm able to check it remotely using a different phone, but that isn't very ideal for me. Try reducing the input gain as per above. | | | | |
Thanks for the info on the settings and confirming that changing those values won't work on my PAP2T.
I'll have to do some test calls with the "FXS Port Input gain" set to a lower value and see if I still get talkoff, mine is set to the default of -3 and some people have said my voice volume is low at this level so I'm not sure how much lower I can make it. I did try setting it to -6 and also -10 and tried to access my voicemail again with Inband DTMF, but that didn't work. I've also tried adjusting the "DTMF Playback Level" to a higher number than the default value of -16 and also the "DTMF Playback length" to a longer value (tried .25 and .50) but that had no affect either.
Appreciate the help and comments from everyone in this thread. | | | |
to brg
said by brg:Wow that's 10 years worth of of a full-time-job-equivalent: 8 hours per day for 5 days a week (= 40 hours), times 50 weeks per year (= 2000 hours assuming [only] 2 weeks vacation) for 10 years straight (= 20,000 hours). What did you do for your day job? I worked for 15 years as an engineer with Ericsson, designing telephony and networking equipment, until the entire division I was employed with was eliminated some 8 years ago. I haven't had a day job since. Instead, I've spent the past 8 years working 16+ hours a day, 7 days a week, 365 1/4 days a year, trying unsuccessfully to develop a viable business of my own. When one spends all waking time doing nothing but work, the hours add up very quickly. There has been no time off at all, except for 5 days in '06 when I went to the beach with my parents, and three weeks dedicated to looking after my mother, after my father passed away two and a half years ago. | | brg
Premium Member
join:2001-01-03
Chicago, IL |
brg
Premium Member
2010-Dec-29 9:47 am
Well, you have mentioned many, many products that a number of us would happily pay for. Some of your Dockstar-related development work comes to mind, for example. But I can find no real marketing, and no sales "point-of-presence." Offer quality products at a fair price and you might well have something viable!  | | | |
to CartDude
said by CartDude:I'll have to do some test calls with the "FXS Port Input gain" set to a lower value and see if I still get talkoff, mine is set to the default of -3 and some people have said my voice volume is low at this level so I'm not sure how much lower I can make it. I did try setting it to -6 and also -10 and tried to access my voicemail again with Inband DTMF, but that didn't work. I've also tried adjusting the "DTMF Playback Level" to a higher number than the default value of -16 and also the "DTMF Playback length" to a longer value (tried .25 and .50) but that had no affect either. If the voice volume is already too low, then lowering it further won't help. On the other hand, too low a level isn't good either for DTMF. You can try raising "FXS Port Input gain" some, although there isn't much room to play with on the upside. You may also want to try using a different phone. "DTMF Playback Level" and "DTMF Playback length" control the volume level and length, respectively, at which out-of-band DTMF from the remote end is played back to you. They do not affect outbound DTMF at all, so playing with them won't help (unless you're also getting DTMF talk-off from the remote end and want to reduce it). | | | DogFace056 |
to brg
said by brg:But I can find no real marketing, and no sales "point-of-presence."
Marketing! Crap, I totally forgot about that. Is it really necessary? Any way around it? | | brg
Premium Member
join:2001-01-03
Chicago, IL |
brg
Premium Member
2010-Dec-30 11:06 am
said by DogFace056:said by brg:But I can find no real marketing, and no sales "point-of-presence."
Marketing! Crap, I totally forgot about that. Is it really necessary? Any way around it? OK; let me amend that. Your work-around is these BBR posts. Maybe that constitutes sufficient marketing for your business plan. Now then; about product availability... | |
|
