Can I Select A Ringtone?

I have a D40 phone and Asterisk 11.2.1. I am developing a custom app for the phone. I would like the phone to use separate ringtones, depending on who is calling me. For example, one for my boss, a different one for co-workers, yet a different one for friends, and so forth.

I can gain control using digium.observe.event, for event name digium.phone.incoming_call. This seems to be a logical place to make a ringtone decision, if one can be made. I can identify the caller at that point. There is a lot of good information available to the callback routine. However, I cannot find any information about setting or selecting the ringtone that would be used to announce the call, once the call (SIP INVITE) comes into the phone.

Is it possible to programatically select the ringtone?

Thanks much in advance.

Howdy,

Negative, the ringtone playback selection for an incoming call is determined by the received “Alert Info” header on the inbound INVITE to the phone.

Cheers

Thank you.

In the dialplan, can I add an “Alert Info” header using SIPAddHeader ahead of the dial command? If so, what do I specify as the value of the header that will correlate with ringtones previously loaded into the phone?

Howdy,

For versions of Asterisk using chan_sip, yes.

Ignore all of the text on this page (as you might not be using DPMA) and just look at the diaplan example here - wiki.asterisk.org/wiki/display/ … d+Intercom

What goes in the angle brackets is the name of the Alert that you’ve put on the phone. If you’re provisioning via XML and you had:

<?xml version="1.0" ?>
<config>
    <ringtones>
        <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>
    </ringtones>
</config>

You could use “normal” “ring-answer” “intercom” or “visual” in the square brackets - minus the quotation marks, of course.

If you’re approaching it from DPMA, it’s a similar thing; use the alert info string you specified for the alert (wiki.asterisk.org/wiki/display/ … ionOptions).

Cheers

Incidentally, if you’re on chan_pjsip, you’ll have to use the PJSIP_HEADER function and you’ll have to pop it onto the outbound leg, so you’ll have to use the Dial b option, e.g.:

exten => 100,1,Dial(PJSIP/alice,,b(pagehandler^addheader^1))

[pagehandler]
exten => addheader,1,Set(PJSIP_HEADER(add,Alert-Info)=<intercom>)

I’m using chan_sip, as opposed to chan_pjsip. CLI module show like chan_sip shows one module loaded; the same for chan_pjsip shows zero modules.

My D40 phone is at firmware level 1_4_0_0_57389 and has 15 ringtones built in. The default one is Digium. If I use the phone’s web interface to change the default ringtone to Office, for example, and call the phone, I get the annoying Cisco-sounding ringtone (no offence to Cisco; they are good in their market; it just sounded like the phones at the last place I was laid off from).

BTW, I don’t have DPMA installed, and I am still manually configuring the phone using the phone’s web interface. I plan to use XML configuration, once I get to the point where I know what to configure. At this point, I have only one Digium phone, used for testing. I have soft SIP phones, running on laptops, that I use to call into the Digium phone.

I updated my dialplan (extensions.conf) to contain the following snippet:

; Dial out to Digium D40 phone, Line 1
exten => 401,1,NoOp()
same => n,SipAddHeader("Alert-Info: ")
same => n,Dial(SIP/D40Line1,10)
same => n,GotoIf($[${DIALSTATUS} = “BUSY”]?busy:unavail)
same => n(unavail),Voicemail(401@CharleysHouse,u)
same => n,Hangup()
same => n(busy),Voicemail(401@CharleysHouse,b)
same => n,Hangup()

When I call the phone, at extension 401, and have CLI sip set debug on, I get the following snippet in the sip debug output:

INVITE sip:D40Line1@192.168.0.225:5060;ob SIP/2.0
Via: SIP/2.0/UDP 192.168.0.7:5060;branch=z9hG4bK216a3feb
Max-Forwards: 70
From: “zCharley” sip:zoipphone@192.168.0.7;tag=as4e231e2c
To: sip:D40Line1@192.168.0.225:5060;ob
Contact: sip:zoipphone@192.168.0.7:5060
Call-ID: 6e4dc15460aaed634b2ff7a6063a80d5@192.168.0.7:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 11.2.1
Date: Tue, 04 Mar 2014 23:26:19 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Alert-Info:
Content-Type: application/sdp
Content-Length: 255

v=0
o=root 602180888 602180888 IN IP4 192.168.0.7
s=Asterisk PBX 11.2.1
c=IN IP4 192.168.0.7
t=0 0
m=audio 17736 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


The Alert-Info header was properly inserted into the INVITE request (at least it looks proper to me…). I am not loading an external ringtone, but I am trying all this using built-in ringtones.

However, the phone still uses the default Digium ringtone. Why is the phone not picking this up?

I tried removing the angle brackets from around the ringtone name, and that had no effect (still used the default Digium ringtone).

RFC 3261, in Section 20.4, describes the Alert-Info header. It does not specify exactly what should be specified as the value of the header, but an example shows specifying a URL and a wav file name, enclosed in angle brackets, as the header value:
Alert-Info: http://www.example.com/sounds/moo.wav

As another test, I coded an instance of Alert-Info with http://192.168.0.7/sounds/moo.wav. I monitored all IP traffic with WireShark after calling the phone at extension 401. There were no IP packets observed coming from the phone after the INVITE packet that were related to the above URL. Since I don’t have a web server there, I would have expected TCP/IP errors of some kind when the nonexistant server did not respond. The phone rang the default Digium ringtone.

Am I missing something here?

— Charley

How are you provisioning your phones? I don’t know if it is possible to have custom ringtones on phones that are configured simply via the screen and phone web page. However, if you are configuring via DPMA, you could add this to your res_digium_phone.conf

[code][alert-google]
type=alert
alert_info=ai-Google
ring_type=normal
ringtone=RotaryPhone

[d40office]
type=phone
network=mynetwork
mac=000fd3069e2e
line=10010
line=10050
full_name=My Name
timezone=America/Louisville
ntp_resync=86400
parking_exten=70
parking_transfer_type=blind
web_ui_enabled=true
record_own_calls=yes
send_to_vm=yes
active_locale=en_US
alert=alert-wakeup
alert=alert-google
blf_unused_linekeys=no[/code]

In this case, I have a special ringtone used for calls that come in via Google Voice. The SipAddHeader would look like

Mollet is correct. The phone doesn’t ship with built-in alerts to know what to do when it receives an Alert-Info. You have to tell the phone what alerts it should respond to and how it should respond. To do that, you’ll be configuring the phone using XML:

wiki.asterisk.org/wiki/display/ … tion+1.4.0

or doing the DPMA thing as mollet noted.

Mollet, thank you!

Malcolm, thank you!

I will set up XML provisioning as described in the XML Configuration 1.4.0 document, and get back to you with whatever problems (I hope none) or success that I have.

— Charley

Greetings, I’m back…

Mollett, sorry for misspelling your name.

I have created an XML provisioning file, mac_address.cfg (with the actual mac address specified in lower case), and I have stored in where my web server (Tomcat in my case) can serve it up. I have used a browser to access the file and display it, so I know it’s in there correctly.

I have updated my DHCP server to send an Option 66 segment that contains the URN for the provioning file as a string. The relevant updates are:

option boot-server code 66 = string;
...
option boot-server "http://192.168.0.7:8080/phoneprov/";

However, when running Wireshark on the Tomcat machine (192.168.0.7), I never see any IP request packets from the phone for this URN. The phone does not appear to be trying to access it.

I ran tcpdump to a file on the DHCP server machine during a restart of the Digium phone, and copied the resulting file to a system with Wireshark, to see it nicely formatted.

What I found was a DHCPDISCOVER from the Digium phone, followed by a DHCPOFFER from DHCP. The phone then sent a DCHPREQUEST followed by DHCP sending a DHCPACK. The OFFER and ACK from DHCP both contain the correct lease and Option 66 tftp server name specified above. This was followed by another DHCPREQUEST from the phone, followed by another DHCPACK. However this last ACK was immediately followed by an ICMP Destination unreachable (Port unreachable). This exchange is using known ports of 67 and 68, but the port unreachable indicates that the destination end (the one getting that last ACK on port 68 from DHCP, the phone) rejects the request on that port. I find this is strange, since this port combination was just used for the DISCOVER/OFFER and the first REQUEST/ACK pairs.

Do I have something misconfigured?

The phone is a black box (charcoal with silver trim, really), so I cannot see or trace anything in it.

Where do I go from here?

— Charley

Howdy,

If the phone was previously configured via DPMA, it’s going to continue to use that configuration method going forward, even if DHCP Option 66 directs it somewhere else, unless the phone has been factory defaulted. So, try factory defaulting your phone.

Cheers

Malcolm,

Excellent advice! I reset the phone to factory defaults and it picked up the DHCP Option 66 URN, accessed it, and loaded the specified config file into the phone. I see the HTTP GET request go by on Wireshark, something I never saw before. The response to the GET is a whole bunch of XML.

I’m not sure why this was necessary, since I don’t have DPMA. I bought this phone new. It came with firmware 1_1_3_0_52406 and I upgraded it to 1_4_0_0_57389. This phone was not marketed as a refurb or as used. I would have thought that a firmware upgrade would effectively be a factory reset.

Anyway, it provisions now. The original reported problems with associating Alert-Info headers with phone ringtones is resolved. I can pick and choose the ringing tone, based on values supplied for the INVITE Alert-Info header. This is good. Thank you for the help with this.

However, I now have some minor problems. I used the example in the XML Configuration 1.4.0 document as the basis for my configuration file. I cut and pasted as needed into my mac_addr.cfg file, updating elements as needed. BTW, there is an error on line 56, in <setting id=“sip_qos”. The value of 1 is not completely enclosed in double quotes. I found this with xmllint. My resulting XML configuration file also passes muster with xmllint.

Now when the phone restarts and eventually registers with Asterisk, it does not display the line labels for the line buttons in the upper right of the display. The icon of a person does not appear after successful registration, also. The label areas are completely blank. I coded values for line_label in in . The entered value shows up on the phone’s web interface, but not on the actual phone. I know the phone registers. It displays a red blinking MWI light and the correct number of outstanding e-mails is displayed. Asterisk also shows it as registered. It also shows both lines as peers. Any ideas?

Also, when I call the phone from another SIP phone (a softphone on a laptop next to the Digium phone), in addition to getting the desired ringtone, the phone answers on the first ring thru the speaker. I never get to lift up the hand set. The results are an incredible howl, as he laptop speakers feed back to the phone speaker (and vice versa). I tried changing the headset_answer element in from 0 to 1 to 0. That’s the only configuration parameter I can find that even looks like it might have an effect. The setting of headset_answer has no effect on this situation. Is there some other parameter that can tell the phone to wait for me to answer it myself?

— Charley

Once the phone has a config on it, a firmware update or downgrade isn’t going to override the config source that the phone’s using. You really wouldn’t want that to happen in practice. As you’d already loaded some config on your phone Option 66 was ignored.

The value in the example is 3. What’s the URL of the page with the example you had a problem with? I loaded the example from:
wiki.asterisk.org/wiki/display/ … tion+1.4.0
and didn’t have that problem.

What does your entire account element look like?

That’s because you’ve set a ring_type of "ring-answer"
If you want a different behavior, you’ll need to use a different ring_type

Yes, this makes sense. I had done some configuring using the web interface and from the phone menus. At this point, I cannot say exactly what I did, or in what order. Factory reset clears the table for a fresh start.

I mistyped. The errant element I should have referenced is two lines down, pc_qos.

[quote]What does your entire account element look like?
[/quote]
My accounts element, with passwords redacted, is:

[code]



<host_primary server=“192.168.0.7” port=“5060” transport=“udp” reregister="300"
retry=“25” num_retries=“5” />

    <!-- Account for Line 2 -->
    <account index="1" status="1" register="1" account_id="D40Line2" username="D40Line2"
             authname="D40Line2" password="xxxx" passcode="xxxx"
             line_label="Line 2" caller_id="D40 Line 2 &lt;402&gt;" >
        <host_primary server="192.168.0.7" port="5060" transport="udp" reregister="300"
              retry="25" num_retries="5" />
        <permission id="record_own_calls" value="0" />  <!-- Only used on DPMA -->
    </account>
</accounts>

[/code]

[quote]That’s because you’ve set a ring_type of "ring-answer"
If you want a different behavior, you’ll need to use a different ring_type[/quote]
Yes, I happened to use “ring-answer” in that instance. Changing it to “normal” made the phone act as one would expect a phone to act. As an experiment, I tried “answer” which simply made the phone answer immediately without any ringtone, and “visual” which ignores the ringtone and displays a message about who is calling.

— Charley

I’ve addressed the example config typo. Thank you for the catch.

I don’t show the same problem you do with line labels. I pasted your accounts block into my test config and I can see the line labels and manipulate them.

Cheers

I know this thread is wandering off topic, but I promise to open a new thread when I hit my next problem not related to this one.

I disabled the Option 66 in my DHCP server, reset the phone back to factory defaults, and told it to continue when it could not find any configuration. I then used the web interface to manually configure the phone, setting up only one line. The below attachment is a screen capture of the resulting display, showing one line, with a line label in place.

[attachment=1]ManConfigOneLine.png[/attachment]
I then reenabled Option 66 in my DHCP server. I updated the configuration file to have only one account in the accounts section. This should configure the phone to have only Line 1. I then configured the phone to return again to factory defaults. It restarted and loaded the XML configuration file pointed to by the URN in Option 66. Below is a screen capture of the resulting display.

[attachment=0]DHCPConfig01.png[/attachment]
Although one account and line_label is configured, the display shows places for two lines. No line labels are evident. The icon showing registration (or not) is missing.

It does not seem to matter the number of account sections specified. Places for two lines and their line labels are shown on the display.

Now, is there anything else anywhere in the XML configuration file that can indicate or specify the number of lines to be configured in a phone?

— Charley

The phone loads each account specified in the order of its index value, with 0 being loaded first.

Since I took your account blocks as-is and pasted them in and things were hunky-dory for me, I’d venture that you’ve got a very subtle configuration error. I’d start by breaking down your XML file into the most basic thing possible, e.g.

<?xml version="1.0" ?>
  <config>
    <accounts>
      <account index="0" status="1" register="1" account_id="100" username="100" authname="100" password="100" passcode="100" line_label="100" caller_id="100" dial_plan="" visual_voicemail="0" voicemail="sip:800@pbx.example.com">
        <host_primary server="pbx.example.com" port="5060" transport="udp" />
      </account>
    </accounts>
  </config>

Malcolm,

Thanks for the encouragement. I’m going to try various combinations of things to see what happens.

I take it that only the element and its subelements affect the number of lines (or places for lines) shown on the phone display. Is this a correct assumption?

To be sure I have a level playing field, I take it that resetting the phone to factory defaults clears as much from the phone (from previous configurations) as possible. The method I have been using is to go to the phone display, select “more”, then “menu”, then “Advanced”, then “Reset to factory default”. Is the correct way? There’s not a magic button somewhere on the phone that I have to stick an unbent paperclip wire into, to reset the phone?

You mention that accounts are loaded in index order. I have a D40 two-line phone. When I specify an account with an index of 0 and another with an index of 9 (beyond the range of any Digium phone), the second account acts like a second line, as if I coded index of 1. It accepts calls directed to that account’s username and shows as that user when the phone is used to create an outgoing call to another SIP phone (a softphone on a laptop). I take it that default behavior for the index value is to assign it to the last line on the phone?

What would the expected behavior be if I removed all account information, including the element?

I’ll keep trying things, and let you know what I find.

Thanks,
— Charley

Almost entirely correct. The phone model itself affects the maximum number of lines but each account defined under accounts should be mapped to an index and the lowest index is assigned to the first line, and so on.

Hah. You’re doing it the right way.

The lowest index # wins the first line, and there on out - though I’m sure you could probe it into weird behavior by specifying some arbitrarily large number.

In that case, you’ll have a phone provisioned with no accounts, but it should still boot.

Cheers

Malcolm,

I found it! It is a very subtle configuration situation, indeed.

After many iterations of commenting out sections of the XML configuration file and restarting the phone by resetting it to factory defaults, I was able to locate the one statement that was causing this problem.

In the long example presented in the Digium “XML Configuration 1.4.0” document, there is a line which reads:

The description of this XML element states, “Applies to D50 and D70 models, enables / disables sidecar, defaults to 1”.

Since I have a D40 model phone which does not come with a sidecar, I set this value to “0”:

This caused the phone to show two empty line label areas, regardless of any (or no) elements specified.

When I changed the value to “1”, the problem went away, and the line labels specified in the elements displayed correctly, along with the registration (or not) icons.

I was able to reproduce this situation with a configuration file consisting of only the desi_strip_enable setting and the two elements I showed earlier in this thread. In this file, I had deleted every other XML statement within except for these. I could even reproduce this problem with only a single desi_strip_enable setting element in a element, alternating values of “0” and “1” on subsequent restarts.

Offhand, I would consider this an error with the firmware in the phone. If nothing else, the documentation should be updated to specify that, for Model D40 phones, always specify “1” for this setting.

The customer workaround for D40 phones, is to either not specify the desi_strip_enable setting at all, or to specify a value of “1” for it. This last is counterintuitive, since the D40 does not have a sidecar to enable or disable, but it seems to work.

— Charley