[asterisk-dev] Any plans for func_config to use sorcery?

[Mark Michelson]

On Wed, Sep 4, 2013 at 5:02 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
>
> On Wed, Sep 4, 2013 at 3:41 PM, Joshua Colp <jcolp at digium.com> wrote:
>
>> George Joseph wrote:
>>
>>>
>>> Gotcha.  If you give me some naming convention guidance, I can work on
>>> both the SIP equivalents and config stuff (which would be needed to
>>> duplicate SIPPEER anyway) using PJSIP_DIAL_CONTACTS and
>>> PJSIP_MEDIA_OFFER as templates.
>>>
>>
>> Changing the names is a minor thing, so just go with what feels right.
>> Note: We have no peers though.
>>
>>
> My personal preference (although I'm certainly open to any alternatives):
>
> SIPPEER -> PJSIP_ENDPOINT
> SIP_HEADER -> PJSIP_HEADER (thoughts below on this)
> SIPCHANINFO -> PJSIP_CHAN_INFO
>
> As far as SipAddHeader/SipRemoveHeader go - it always felt a little wonky
> that these were dialplan applications, particularly when we have SIP_HEADER
> as a function. It feels like this could be easily:
>
> ${PJSIP_HEADER(X-foo)} - equivalent to SIP_HEADER
> Set(PJSIP_HEADER(X-foo)=bar) - equivalent to SipAddHeader
> Set(PJSIP_HEADER(X-foo)=) - equivalent to SipRemoveHeader
>
> The last one is the most tricky, as it is debatable whether or not certain
> headers (such as Allow) can be empty. If we need to allow empty headers,
> another option would be to explicitly specify 'remove' as the second
> parameter to the function:
>
> Set(PJSIP_HEADER(X-foo,remove)=)
>
> Just some thoughts.
>
> It'd be fantastic for someone to contribute those patches - let us know if
> you need any help/pointers!
>
>
I've spent a bit of time giving some thoughts to implementation details of
PJSIP_HEADER.

The challenge is that in chan_sip.c, the initial request that started a
dialog is cached on the sip_pvt struct. This can easily be queried from the
dialplan. With PJSIP, the pjsip_rx_data for the initial INVITE has been
freed by the time the dialplan runs.

My thought is to write a session supplement that is triggered on incoming
INVITEs. The module that implements the session supplement would also
implement the PJSIP_HEADER dialplan function.

On an incoming INVITE, the session supplement would use pjsip_msg_clone()
in order to make a copy of the rdata->msg_info.msg. This could then be
stored on a datastore on the session. When PJSIP_HEADER() is called in
order to read a specific header, the datastore can be retrieved from the
session and pjsip_msg_find_hdr_by_name() can be used to find the value of a
specific header.

As for PJIPAddHeader (or making PJSIP_HEADER operate in write mode to add
headers), this could be done similarly, but in reverse. When PJSIPAddHeader
is called, the proposed header could be stored on the session in a
datastore. On an outgoing INVITE, the session supplement could query the
datastore for extra headers to add and call ast_sip_add_header() to add the
headers to the outgoing request. If you look at
res/res_pjsip/pjsip_global_headers.c, you can see an example of adding
headers from a list onto requests and responses; however, that file does
not make use of a datastore.

One further note: PJSIPAddHeader should not work the same way that it
currently does for chan_sip.c. In chan_sip.c, you call SIPAddHeader on an
incoming call and the header is then added to the outgoing call's INVITE.
For PJSIP, we should only ever modify the relevant session. If people want
to add headers to an outgoing INVITE, then they can use PJSIPAddHeader in a
predial handler. This adds the flexibility, if desired, of adding specific
headers to specific outgoing call legs without forcing the same headers on
all outgoing call legs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130905/6064b546/attachment.htm>