On Thu, May 18, 2017 at 12:39 AM, Yasin CANER <[email protected]> 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@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
-- _____________________________________________________________________ -- 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
