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

[Richard Mudgett]

On Thu, Jul 27, 2017 at 10:31 PM, Kirill Katsnelson <kkm at smartaction.com>
wrote:

> There were users asking for this feature for as long as I have been using
> Asterisk, albeit the requests are infrequent. Basically, when the
> transferrer initiates transfer with a SIP REFER message, we want access to
> some interesting (normally additional) headers in this message from the
> dialplan.
>
> I currently have an implementation that extracts headers into the parent
> channel's dialplan hash with the fixed name TRANSFER_DATA. Header name
> becomes the key, value the data under this key. Duplicate header names not
> supported (later in the message wins its spot in the hash). This part looks
> good to me. I am dismissing any need to support duplicates, as probably
> there is about 0 users in the world who would want that.
>
> I want to submit a patch for this feature. What I do not know, is the best
> way to specify which headers the user wants in the hash. In my current
> code, the parent channel than wants the data sets a variable
> TRANSFER_SIPHEADER_PREFIX to the prefix matching the interesting header
> names. In my case the prefix is "X-" for all "extended" headers. I imagine
> other users may want to set that to a specific name (e. g.
> "X-Altitude-Data", see https://community.asterisk.org
> /t/how-to-send-variable-information-via-sip-header/70178/7). If not set,
> no headers are put in the hash (unchanged behavior).
>
> I am not sure if this is a good approach. I would appreciate suggestions
> to make the interface as good as it should be. Basically, what I am
> undecided on is:
>
> 1. Is variable a good way to specify the headers? I cannot find a place to
> document it. Options here: a setting in sip.conf (inflexible); a function
> that sets the variable (better, self-documenting).
>

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.

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.


>
> 2. Is prefix a good way to specify the pattern? Options: regex (more
> flexible but computationally expensive); wildcards (but we have no
> functions to readily support them).
>

Again I think the prefix approach is good enough.  Using a regex is
somewhat overkill and you would have to build more support infrastructure.
However, I think that an empty prefix string value to match all headers has
a subtle problem.  It can conceivably get confused with the variable not
existing and you cannot disable the feature once it is enabled on the
channel.  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.


>
> Somewhat related to the question 2, another thing I want to add as we are
> at it is function SIP_HEADERS([pattern]) to complement SIP_HEADER(), that
> would return an array of header names matching the pattern from the
> incoming INVITE. Whether the function itself a matter of additional
> discussion or not, I want the syntax of the pattern be same in both places,
> so this is a related part.
>

The SIP_HEADERS function is very useful to find out what headers were
included in the INVITE.  To extend the concept to other areas,
PJSIP_HEADERS and MESSAGE_DATA_HEADERS functions would be just as useful
for the same reason and get core support.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170801/7d5cbe1c/attachment.html>