Digium Phones - ring-answer instead of Ring Answer

General Help
1

Frustration!

Got to see the new Digium phones at Astricon and then waited patiently for them to ship - Finally got them a few weeks ago, and they are pretty good - really good at Auto-Provisioning, but I am up against a problem that is really frustrating, and I am wondering if there is already a solution, or if I can get some direction and volunteer to implement a solution.

In their infinite (?!?) wisdom, Digium set up the alert_info as follows:

alerts
alert alert_info=“normal” ringtone_id=“Digium” ring_type=“normal"
alert alert_info=“ring-answer” ringtone_id=“Digium” ring_type=“ring-answer"
alert alert_info=“intercom” ringtone_id=”” ring_type=“answer"
alert alert_info=“visual” ringtone_id=”" ring_type="visual"
alerts

Which is NOT the same as Polycom - Polycom expects “Ring Answer” and that is what is coded into the FreePBX Dialplan.

Because of this, the following functions fail:

Paging
Intercom

Also, iSymphony inserts a “Ring Answer” into the AMI when you try and dial a number using the interface - so it fails too.

One of the main reasons I got excited about the Digium phones was the ease of provisioning and revision of provisioning.

In talking to Digium, their response was that I could create a custom XML file for each phone and change the code like I wanted - That pretty much defeats the whole purpose of DPMA in my book.

So after all that preamble, here is the real question - how hard would it be to add a field into the extension definition for the various alert_info fields that FreePBX uses - If I can get some guidance on which modules to modify I can prototype the change and then upload the work - I don’t think FreePBX uses anything other than “Ring Answer” but I guess that is also some guidance I need.

Also, in looking around for a solution to this problem, I did see several posts about other phones needing the Dialplan modified to have the Page work for them, so I think that this might be a useful feature overall.

Thanks in advance, and I am ready to help - I just need some direction as to where to start!

Greg

2

The Alert-Info headers for the paging module are database driven.

If you look at the install script you will see some examples for setup of some other phones that deviate from the “norm.”

You can follow that lead by making similar entries based on the Digium phone uesragent info. Once you have done that, feel free to open a ticket and provide what you added so we can have a look at maybe adding it to the install script.

When you make additions to the appropriate database tables in the paging module, they will not be overwritten. They are designed to allow you to customize for the environment.

If I’m not mistaking, we used to cover this in OTTS though it’s possible in our recent course changes we removed this specific section since it is pretty unique and not needed by most people.

3

Well, I tried to get Digium to fix this and they won’t so here is a work-around:

Open the file /usr/lib/asterisk/modules/res_digium_phones.so in a Hex editor.

Go to Offset 000F2D10 - Here is what is looks like:

6F 3D 22 72 69 6E 67 2D 61 6E 73 77 65 72 22 20 - o=“ring-answer”

Change it to:

6F 3D 22 52 69 6E 67 20 41 6E 73 77 65 72 22 20 - o=“Ring Answer”

Save the file, reload Asterisk and then go to Connectivity -> Digium Phones and hit Reconfigure All and then life is good.

What a bunch of Crap! Shame on you Digium!

Greg

4

The real question is why cant you change that in the config file of the phone. Why does a asterisk .so file control things like alert infos

5

“Well, I tried to get Digium to fix this and they won’t so here is a work-around:”

You brought it to our attention. Thank you. What do you mean, that we won’t fix it? Do you mean that we won’t roll a new res_digium_phone.so for you today, or do you mean that we told you to take a hike? I’m pretty sure it’s just the first, since I’m kind of “in the know” on these things, and since I’m right now looking at the ticket where we’re going to add the additional alert in the forthcoming 1.1 DPMA release. If it’s the later, someone told you wrong. Sorry about that.

“What a bunch of Crap! Shame on you Digium!”

We didn’t have something in the product that could make your life easier. We’re going to add it. It’s good to blow off steam, but there aren’t any bad guys here.

For the benefit of anyone reading this thread, you can send feature requests for Digium’s phone products to:

[email protected]

Cheers.

6

As far as Digium’s response, here is from the E-Mail I received from Alice Scanland at Digium:

“This is actually a FreePBX issue in that they don’t allow you to easily implement support for other devices and how they use alertinfo. We have 4 messages we support today in our DPMA and if Free PBX would send the correct one paging would work. This can be fixed by going into the database of FreepBX and making the change, Phillipe at FreePBX recently posted on this. But we are working on a new version of DPMA (1.1) and we are going to add the ability to recognize the Polycom alertinfo message for paging and interrupt it as our message. In the short term this can be addressed by changing the database in FreePBX.”

This is wrong on two points - first, if I change what FreePBX sends out, and it is not an all Digium environment, I have broken the other phones, so that is certainly not an option. I know that FreePBX should have this ability independently for each SIP extension - that is the majority of the original post - asking for guidance on how to do that.

Secondly, as my instructions show, it is hard-coded into the resource module - Why? This could be easily fixed if it were reading from a .conf file instead of hard-coded in to the module - Work with the community - if you put settings into editable files instead of hard-coding them into binaries, this would have been a 2-second fix instead of my asking for a patched module.

As far as this being new, I have been talking to various people at Digium for almost a month now. Their suggested solution was to go to hard-coded XML conf files for each phone - that kind of defeats the purpose of DPMA don’t you think?

My whole purpose of going to Astricon was to try and find a way that I could support Digium since I use the free version of Asterisk and other than G.729 and FAX For Asterisk licenses, you all were getting no revenue and I for one am very keen on seeing Asterisk continue to grow and develop. We used to use only Digium telephony cards for the same reason, but 99% of all our installs are SIP now.

I badly want to sell Digium phones with our systems, but when you break features that our customers insist upon for no reason (Truly, you can’t come up with a reason why ring-answer is superior to Ring Answer…) it makes it hard to stay excited!

You’re picking on the wrong guy here - Instead of flaming me, you should be asking the phone developers who thought this was a good idea - 20 minutes of testing with anybody who uses FreePBX would have revealed this problem and the easy solution.

Greg

7

Maybe I just don’t understand the Digium phones and how they get configured yet but why cant you set the alert info in a config file for the phone like most other phones? None of us at FreePBX have gotten our hands on a Digium phone yet to test this stuff and try to help work through questions like this. We seem to have every other brand phone in our labs.



And for those who are curious that is Philippe on the right (p_lindheimer) our fearless project leader and Bryan on the left (GameGamer43) working on some intensive debugging with FreePBX yesterday on this elusive memory leak that random people have been reporting in FreePBX 2.10.

8

Concerning the question of configuring Alert-Info in FreePBX…

In an email to GSnover (apparently):

It is my understanding that Digium is providing a FreePBX module to support their phones. As I previously mentioned, additional “auto-answer” (Alert-Info, Call-Info, etc.) can be added to the paging module in the database to handle a diverse set of phones. In fact, it is possible for any partial or specific phone User Agent to have a different Alert-Info. This would, for example, allow a mixed environment such as older and newer versions of Polycom phones, where they have changed what they used, to co-exist if they differentiate their User Agent as many manufacturers do by putting everything down to the firmware revision in the User Agent.

This database mode was designed many releases ago for the explicit purpose of addressing a diverse set of phones and the flexibility goes beyond simply SIP headers which is beyond the scope of this post. The design was done with the intent of modules such as an Endpoint Manager having the ability to add needed information for specific types of phones and in such a way that doing such would not break the paging/auto-answer and further more, the paging module would never trample on top of any new additions when upgraded.

As I’ve mentioned, there are examples in the install.php script for the paging module on how some of these can be answered. I would expect that Digium, in their FreePBX module, would simply add the required entry to the paging module table so as to get their phones to work. The developers have full access to the FreePBX team when requested and we never have any issue pointing them in the right direction.

Anyhow, I’m sure it will all get worked out in the end. GSnover, feel free to PM me in the interim if you would like more details on how to solve this issue in your installations if you don’t want to be patching binaries…

9

For anyone who wants to add support for Digium phones for auto answer into FreePBX do the following from the linux CLI
[list=1]
[] Connect to the mysql database with
amportal a m
[] Update the paging auto answer table with the alert info for Digium phones:
INSERT INTO paging_autoanswer (useragent, var, setting) VALUES ('Digium', 'ALERTINFO', 'Alert-Info: ring-answer');
[/list]
Now anytime FreePBX looks to send an alert info to a Digium phone only it will use the ring-answer alert info not the default ring answer. You could also replace ring-answer with intercom based on what alert info’s the Digium phone supports.

EDIT: amportal a m automatically connects to FreePBX’s database. One less step! --mbrevda

10

I didn’t understand Philippe’s original post or I would have went this route - I think this is better than Patching the binary - but it does lead to another question on my part - Would I be better to work on a Manufacturer Field in a SIP Extension definition, or just an Alert-Info field? While it would be more work to have to enter an AlertInfo for every extension (I guess it could default to “Ring Answer”) I think it would be more flexible than blanket definitions for each manufacturer.

What I am thinking is that if I have it as a setting for each SIP extension, then user A could have “Ring Answer” (or “ring-answer” if they are Digium…) but user B could prefer (and be accommodated) using “Intercom” rather than having a default for each brand.

That is what I am working on right now.

Greg

11

Greg,

adding the field simply leads the dialplan to check the specific device’s user-agent prior to setting the Alert-Info field.

So … any extension that is a Digium phone, in this example, will have a different Alert-Info set. That is why it makes sense for their module to add that to the database table if not already there. When the FreePBX team get’s phone to test and confirm, we will be adding it to the paging module as we have with some other phones though when done right, it doesn’t matter if they are already there as it will then be ignored.

Here is a snapshot of the generate dialplan to help you understand how it is conditionally sending different Alert-Info’s to different phones:

[macro-autoanswer]
exten => s,1,Set(DIAL=${DB(DEVICE/${ARG1}/dial)})
exten => s,n,ExecIf($["${DIAL:0:3}" = "ZAP"]?Set(DIAL=DAHDI${DIAL:3}))
exten => s,n,GotoIf($["${DB(DEVICE/${ARG1}/autoanswer/macro)}" != "" ]?macro)
exten => s,n,Set(phone=${SIPPEER(${CUT(DIAL,/,2)}:useragent)})
exten => s,n,ExecIf($["${phone:0:5}" = "Mitel"]?Set(CALLINFO=Call-Info: <sip:broadworks.net>\;answer-after=0))
exten => s,n,ExecIf($["${phone:0:9}" = "Panasonic"]?Set(ALERTINFO=Alert-Info: Intercom))
exten => s,n,ExecIf($["${ALERTINFO}" != ""]?SipAddHeader(${ALERTINFO}))
exten => s,n,ExecIf($["${CALLINFO}" != ""]?SipAddHeader(${CALLINFO}))
exten => s,n,ExecIf($["${SIPURI}" != ""]?Set(__SIP_URI_OPTIONS=${SIPURI}))
exten => s,n+2(macro),Macro(${DB(DEVICE/${ARG1}/autoanswer/macro)},${ARG1})

That is the macro used for auto-answering. You can see that we pull the user agent from the specific phone:

exten => s,n,Set(phone=${SIPPEER(${CUT(DIAL,/,2)}:useragent)})

then we check for all the exceptions and only after that do we use the other provided defaults (previously set outside the macro) if nothing was set there.