[asterisk-dev] New feature for chan_pjsip : res_pjsip_session : Using DNID variable to change to uri number part

[Richard Mudgett]

On Thu, May 18, 2017 at 12:39 AM, Yasin CANER <yasin.caner at netgsm.com.tr>
wrote:

>     Hello,
>     After chan_pjsip is added in asterisk  channels and asterisk
> improvement  goes to chan_sip to chan_pjsip , i tried to move my network to
> chan_pjsip. one feature has chan_sip but not chan_pjsip that i use   ,
> exclamation mark in Dial to change to uri number part.
>     So i added a function to solve this problem or missing feature in
> res_pjsip_session.
>     Why did i use the DNID in Callerid. in wiki asterisk it has a
> explanation that dialed party number. so it suits me and has a
> variable/struct in asterisk channel, it makes easy to use. In addition it
> is kinda changin Callerid number part.
>
>     if i cant add this feature or solve this problem , i cant update my
> network , soon or later , i have to change my asterisk to another because i
> know that chan_sip gonna stop to improve in a day.
>
>
>     Why i need it. Because some FXS devices like Dinstar waits Request Uri
> number and To uri number must be same. if not , it declines or drop the
> calls.
>
>     How does it work that in here with .jpeg
> https://issues.asterisk.org/jira/browse/ASTERISK-26957
>
>     i tried to so many way to solve this issue with Matt Jordan and others.
>     here;
>  https://community.asterisk.org/t/way-to-get-toheader-name-
> or-number/68717/6
>  https://community.asterisk.org/t/asterisk-13-pjsip-manipula
> te-to-header-on-dial/67550
>
>     my commit
>     https://gerrit.asterisk.org/#/c/5545/


The Dialed Number IDentifier (DNID) is defined as an incoming value which
represents the dialed number to reach the server.  Making it do something
different for outgoing channels overloads its meaning and is likely to
break something.

I think the dialplan function PJSIP_HEADER could be extended to work on
outgoing channels to read/construct the To header string from the channel
dialog remote information and also set/modify the To header in a limited
manner to get what you need.  The To header would be an exception to the
normal header processing done by the dialplan function.

Its use in dialplan would be something like below:

; ------------------------------------------
exten = _X.,1,NoOp()
same = n,Dial(PJSIP/endpoint,,b(pre_dial,1))
same = n,Hangup()

exten = pre_dial,1,NoOp()
;
; PJSIP_HEADER extended to read the To header out of the
session->inv_session
; dialog for outgoing channels because it otherwise isn't available.
;
same = n,Set(TO_HEADER_VALUE=${PJSIP_HEADER(read,to)})
;
; PJSIP_HEADER extended to set limited fields of a To header into the
; session->inv_session dialog for outgoing channels because it otherwise
; isn't available to modify.
; To: "test-name" <sip:testuser at remote-address[:remote-port]>
;
same = n,Set(PJSIP_HEADER(update,to)=${TO_HEADER_VALUE})
same = n,Return()
; ------------------------------------------

Only the read and update actions would support doing anything with the To
header in an outgoing channel situation.  The read and update actions must
first check if the To header is in the list of headers to guard against
trying to manipulate the To header on an incoming channel.  I'm fairly
sure that an incoming channel has the To header stored in its list of
headers automatically.

Helpful functions that could make the patch easier to implement.

pjsip_uri_print() - Use this C function to create the To header string for
the read.

pjsip_parse_hdr() - Use this C function to parse the set To header.  You
then need to update the session->inv_session dialog with new data that is
allowable to be changed.  Allowing unrestricted modification of the To
header is not a good thing as it would defeat what has already been done
and may interfere or get overwritten with what may still be done.

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