New Alert-Info format disrupts distinctive ringtone on some phones

macpip · March 6, 2019, 1:40pm

Short story:

Alert-Info header format changed from

Alert-Info: foo

to

Alert-Info: <http://127.0.0.1>;info=foo

this way it’s no more compatible with some phones.
Temporary solved by editing extensions_additional.conf
Requiring a final solution.

Request:

I would appreciate very much if, after many years working in a not strictly RFC compliant way, but indeed phone compliant, the FreePBX GUI could give me the opportunity (maybe just a flag in the GUI?) to choose if I want to continue to use the old Alert-Info format or if I prefer the new, strictly RFC compliant one.

Note: Using such a flag/option, one could just pass RFC compliant headers by typing

<http://my.preferred.url/bar/myring.wav\>;info=foo

in the GUI text field Connectivity - Inbound Routes - General - Alert info resulting in the header:

Alert-Info: <http://my.preferred.url/bar/myring.wav\>;info=foo

Detailed story:

Since last Friday, when I upgraded FeePBX to 14.0.5.25 (now core is at version 14.0.18.49) and Asterisk to 13.22.0, distinctive ringtone on my Cisco SPA 303 phones did not work any more.
After last upgrade the phones rung the same (default) tone independently on the source of the call, while, before upgrading, they rung differently when the call came from inside or outside.

After some analysis I found that the problem is the new format of the Alert-Info header in the sip INVITE.

Let’s say that I set Connectivity - Inbound Routes - General - Alert info to

foo

the new version sends to the phones an INVITE packet with the following Alert-Info header

Alert-Info: <http://127.0.0.1>;info=foo

while, in the previous version it was simply

Alert-Info: foo

While the new format is compliant to RFC7462, my phones are not able to parse the new Alert-Info format so they ignore the header at all, not paying the different ringtone.

Now, my phones are old, but work perfectly, as I suppose, many other similar phones all over the world do. We cannot expect Cisco (or other manufacturer) to release new firmwares for them.

Temporary solved:

By now I’ve temporary solved the issue by manually editing the file

/etc/asterisk/extensions_additional.conf

replacing

exten => xxxxxxxxxz,n,Set(__ALERT_INFO=foo)

with

exten => xxxxxxxxxx,n,SIPAddHeader(Alert-Info: foo)

like previous FreePBX versions.
But, this way, I will need to re-edit the file it every time FreePBX will have applied some changes.
Please,

Does anybody know if there is a way to keep the change to persist to Freepbx reload?
Or any way to re-enable in FreePBX the old Alert-Info format?
Someone with the same issue?
Should post the request elsewhere?

cynjut · March 6, 2019, 4:01pm

I could have sworn that this was identified and fixed a couple months ago. @tm1000 handled this himself, as I recall.

There might be new semantics in the GUI to turn off the URL part of the Alert-Info, but I distinctly remember talking about this. What version of FreePBX are you using?

jdos77 · March 6, 2019, 5:09pm

I’m having the same problem with Digium D70 phones. I ended up commenting out the line that creates the new Alert-Info format in /var/www/html/admin/modules/functions.inc/func-sipheaders.php. I know that will get overwritten with the next update, but at least I don’t have to re-edit extensions_additional.conf after every config change. I’ve also opened a case with Digium to see if they can do anything on their end.

tm1000 · March 6, 2019, 5:28pm

Unfortunately that follows the RFC for Alert-Info. If a phone manufacturer doesn’t want to follow the SIP RFC for Alert-Info that is on them not Sangoma.

I know this might sound rude but there is another example in the reverse format where as Yealink is now following the RFC for BLF which breaks how Asterisk works and Yealink is saying that it is an Asterisk issue there and refusing to do compromises to their BLF sub routines in the phones. if other phone manufacturers won’t make compromises for FreePBX then why should FreePBX bow to the whims of those not following RFCs?

macpip · March 6, 2019, 5:33pm

I just saw something related to escaping the < and > simbols. Am I wrong?

tm1000 · March 6, 2019, 5:36pm

For Digium phones there is no alert-info defined. I believe one needs to either go into EPM or the Digium Phones module and set it to recognize the correct Alert Info format.

macpip · March 6, 2019, 6:08pm

Sure! The point is that Asterisk & FreePBX too have been working for many years without following the SIP RFC for Alert-Info. This is probably why there was no need for the manufacturers to provide new firmwares to be RFC compliant.

Just because sometimes the manufacturer (Cisco in my case) does not support any more old phones that have been working fine with FreePBX for many years.

To me the main issue is FreePBX’s lack of compatibility with previous releases.

My request is just to maintain that compatibility just adding a flag that permits to use the old

exten => xxxxxxxxxx,n,SIPAddHeader(Alert-Info: foo)

instead of the new

exten => xxxxxxxxxz,n,Set(__ALERT_INFO=foo)

in extensions_additional.conf

tm1000 · March 6, 2019, 6:17pm

@macpip

What if we do what you originally mentioned. An Advanced setting “Do not enforce Alert-Info RFC7462”. I guess the unfortunate part would be that we would have this disabled by default (EG force people to conform to RFC7462)

It still does that. You need to use __ALERT_INFO

It’s about how to conforms it near the end

See

github.com

FreePBX/core/blob/release/14.0/functions.inc/func-sipheaders.php#L32


      
          $ext->add($c,$e,'', new ext_set('SIPHEADERKEYS', '${HASHKEYS(SIPHEADERS)}'));
          $ext->add($c,$e,'', new ext_while('$["${SET(sipkey=${SHIFT(SIPHEADERKEYS)})}" != ""]'));
          $ext->add($c,$e,'', new ext_set('sipheader', '${HASH(SIPHEADERS,${sipkey})}'));
          $driver = \FreePBX::Config()->get("ASTSIPDRIVER");
          if (in_array($driver,array("both","chan_sip"))) {
          	$ext->add($c,$e,'', new ext_execif('$["${sipheader}" = "unset" & "${TECH}" = "SIP"]','SIPRemoveHeader','${sipkey}:'));
          }
          if (in_array($driver,array("both","chan_pjsip"))) {
          	$ext->add($c,$e,'', new ext_execif('$["${sipheader}" = "unset" & "${TECH}" = "PJSIP"]','Set','PJSIP_HEADER(remove,${sipkey})='));
          }
          
          if(\FreePBX::Config()->get('RFC7462')) {
          	$ext->add($c,$e,'', new ext_execif('$["${sipheader}" != "unset" & "${sipkey}" = "Alert-Info" & ${REGEX("^<[^>]*>" ${sipheader})} != 1 & ${REGEX("\;info=" ${sipheader})} != 1]', 'Set', 'sipheader=<http://127.0.0.1>\;info=${sipheader}'));
          	$ext->add($c,$e,'', new ext_execif('$["${sipheader}" != "unset" & "${sipkey}" = "Alert-Info" & ${REGEX("^<[^>]*>" ${sipheader})} != 1]', 'Set', 'sipheader=<http://127.0.0.1>${sipheader}'));
          }
          
          if(in_array($driver,array("both","chan_sip"))) {
          	$ext->add($c,$e,'', new ext_execif('$["${TECH}" = "SIP" & "${sipheader}" != "unset" ]','SIPAddHeader','${sipkey}:${sipheader}'));
          }
          if(in_array($driver,array("both","chan_pjsip"))) {
          	$ext->add($c,$e,'', new ext_execif('$["${TECH}" = "PJSIP" & "${sipheader}" != "unset"]','Set','PJSIP_HEADER(add,${sipkey})=${sipheader}'));

macpip · March 6, 2019, 7:37pm

@tm1000

Would be wonderful! Thanks! Sure, disabled by default.

Just to clarify: old Cisco phones need Alert-Info: RingName no URI at all.

Maybe you were referring to:

Not to:

Or am I missing something?

tm1000 · March 6, 2019, 7:38pm

If you edit FreePBX/core/blob/release/14.0/functions.inc/func-sipheaders.php

and remove line 32 ( FreePBX/core/blob/release/14.0/functions.inc/func-sipheaders.php#L32)

Then reloaded you’d have the same result.

macpip · March 11, 2019, 5:18pm

@tm1000

So, should I wait for an update of the core module or what else?

system · March 18, 2019, 5:18pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.