Pass-through Alert-Info header from phone

Using FreePBX / Asterisk 16.21.1 on Raspberry Pi 3B.

I have a lot of Grandstream phones (several models, including GXV3380, GXP2170, and DP722). These phones have a built-in “Intercom” feature that adds these headers to the SIP INVITE:

Call-Info: <sip:IP.ADDRESS>;answer-after=0
Alert-Info: <sip:IP.ADDRESS>;info=alert-autoanswer;delay=0

I also have the FreePBX Paging/Intercom module set up, so I can do paging using the *80 feature code, but my (very non-technical) users want to be able to just push the intercom button on the phone “because that’s what it’s there for.”

If I understand correctly, the reason this doesn’t work is because FreePBX does not copy the incoming INVITE headers into the outgoing INVITE that is sent to the other phone. When I use *80, the outgoing INVITE has Call-Info and Alert-Info headers, but when I press the Intercom button, the outgoing INVITE does not have those headers. It seems that the simplest way to implement this would be to allow FreePBX to detect those headers and copy them into the new INVITE.

Another discussion on this forum from 2015 (I can’t post the link, but search for “Preserve Alert-Info header”) seems to be asking for the same thing, and I was wondering if there’s any new/better way to do this that has been made available in the last 6+ years.

In the “Advanced Settings” section, I see the “Internal Alert Info” settings, which is described like this:

Alert Info to use on Extension to Extension Calls. ‘Inherit’ will use the previously set Alert Info,‘Unset’ will remove the previously set Alert Info.

The value defaults to inherit. It seems to me that this setting already describes what I am trying to do, but looking at the SIP messages (using sngrep) shows that it clearly doesn’t do what I expect.

FreePBX/Asterisk is a B2BUA, so it creates a new call and copies little to no information from the headers that are needed for the second call.

If you want, you can use the predial hook to check if these headers are present and apply them to the new channel.

Inherit applies if there is already an Alert-Info header on that channel. In your case there are no Alert-Info headers on the new channel.

1 Like

@PitzKey Thanks for the link. It looks like getting this working with a predial hook is probably just as complicated as what I’m doing now, and the only benefit is not having to change the context used by the phone.

In case anyone else is trying to do this, here is what I have right now in extensions_custom.conf that works for PJSIP and legacy SIP channels:

exten => _.,1,Noop(Checking for Alert-Info Header for intercom call from ${CHANNEL})
 same => n,Set(TECH=${CUT(CHANNEL,/,1)})
 same => n,ExecIf($["${TECH}" = "SIP"]?Set(ALERTHEADER="${CUT(SIP_HEADER(Alert-Info),\;,2)}"))
 same => n,ExecIf($["${TECH}" = "PJSIP"]?Set(ALERTHEADER="${CUT(PJSIP_HEADER(read,Alert-Info),\;,2)}"))
 same => n,Set(WANTINTERCOM="info=alert-autoanswer")
 same => n,GotoIf($[${WANTINTERCOM} = ${ALERTHEADER}]?from-internal,*80${EXTEN},1:from-internal,${EXTEN},1)

Then any extension that can use this feature needs to be switch from the from-internal context to the from-internal-with-intercom context. Instead of modifying the headers of the INVITE, this just changes the number being called and then goes into the regular context.

(If someone is using a different intercom feature code than the default *80, that has to be changed in the last line.)

1 Like

Can you not just reprogram the endpoint button to dial *80 instead of its default behavior?

@sorvani Technically I could just make Speed Dial keys that include the feature code, but the built-in Intercom key feature cannot be modified as far as I can tell.

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