[asterisk-dev] Feature discussion: extract REFER headers into dialplan.

Kirill Katsnelson kkm at smartaction.com
Tue Aug 1 16:30:58 CDT 2017


Thank you for the comments!

On 170801 1119, Richard Mudgett wrote:
> On Thu, Jul 27, 2017 at 10:31 PM, Kirill Katsnelson <kkm at smartaction.com>
> wrote:
> The variable approach that you have implemented in the gerrit review (
> https://gerrit.asterisk.org/#/c/6118/ ) is a good way and certainly the
> easier way.  You are able to build on existing functionality rather than
> having to create a lot of support infrastructure if you tried to go the
> dialplan function route.  Another thought arguing in favor of channel
> variables is that the channel being blind transferred by the REFER is not
> necessarily a SIP channel.

This is why I tried to keep variable and hash names non-specific to 
channel or message--I am rather thinking of "some additional data sent 
by the transferrer". So the pjsip channel can certainly share the same 
names. I do not know enough of other channels with similar concept 
applicable, but I believe it can represent most additional data, 
whatever it is.

> As to documentation, you would need to add a section in sip.conf.sample to
> describe the functionality as it is currently chan_sip specific.  If you
> add support for the functionality in chan_pjsip/res_pjsip then it would
> need documentation in the pjsip.conf.sample file.

We are not yet on pjsip; we have been developing on chan_sip specifics 
for a very long time. There are dependencies on AMI events and actions, 
specific documented behaviors, and probably even some undocumented ("it 
just worked"), you name it.  So it's in the plans, but we are not there 
yet. I'll certainly add the same functionality to pjsip when we are 
migrating, we depend on it now.


> I suggest using an asterisk '*' as the match any header value
> instead so an empty or non-existing variable can mean the feature is
> disabled.

Certainly, a very good point about unassigning the variable, thanks!

  -kkm



More information about the asterisk-dev mailing list