<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 27, 2017 at 10:31 PM, Kirill Katsnelson <span dir="ltr"><<a href="mailto:kkm@smartaction.com" target="_blank">kkm@smartaction.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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 <a href="https://community.asterisk.org/t/how-to-send-variable-information-via-sip-header/70178/7" rel="noreferrer" target="_blank">https://community.asterisk.org<wbr>/t/how-to-send-variable-inform<wbr>ation-via-sip-header/70178/7</a>). If not set, no headers are put in the hash (unchanged behavior).<br>
<br>
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:<br>
<br>
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).<br></blockquote><div><br></div><div>The variable approach that you have implemented in the gerrit review ( <a href="https://gerrit.asterisk.org/#/c/6118/">https://gerrit.asterisk.org/#/c/6118/</a> ) 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.<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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).<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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.<br><br></div><div>Richard<br></div></div><br></div></div>