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).
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).
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.
-kkm
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
