And it doesn’t look like there is any other variable to read - so now, I am wondering why this is going awry - the CallerID Override function in the DISA seems to be working - and yet I end up with the wrong CallerID.
This is not going to work as you think. You cannot set the From Header that way. The From Header is going to be populated with the CallerID number. This is why the fromuser= and fromdomain= settings exist so you can change them to the needed things while the CallerID is sent via RPID or PAI.
So what do you need to set the From Header to for the provider? And why isn’t this done in the trunk endpoint/peer settings? Or do you need to set the CallerID per call based on the company using it?
Yeah, I just confirmed that this isn’t working the way you think it is straight from Asterisk devs. First, SIPAddHeader() does that, it adds headers it doesn’t alter them. Asterisk sets the To and From headers on its own due to the tags and other attributes needed in the header. So Asterisk completely ignores any attempts to alter the To/From headers with SIPAddHeader() or PJSIP_HEADER().
It will alter those headers based on the peer/endpoint settings (fromdomain, fromuser) or with Chan_SIP you can alter them in the Dial() string. But using the header functions is completely ignored.
And in the case Chan_SIP is somehow letting the From header be added it will still override it basically because the From header Asterisk adds would be considered the “top most” header and since there is only supposed to be one From header in a SIP message all subsequent From headers are not even looked at by the other side. So sure, it could be added but it is probably being ignored as it would be an additional header that shouldn’t exist.
What a silly thing to say - That code snippet was added specifically to put the Outbound Caller ID in the FROM header - code in place, outbound call works, code not in place, outbound call fails.
What are you trying to add to the conversation here? I was looking for some help with getting the proper Caller-ID outpulsed from a DISA given the constraints this PBX with this provider operates under - you are wasting everyone’s time trying to say that code that is working doesn’t work?
Enough - I will find a solution somewhere else - stop trying to “help” - you are wasting everyone’s time.
You’re doing something that you think does one thing but Asterisk devs says isn’t happening. But OK, I was trying to help by making sure that you understand how this works. Like I said Chan_SIP may be adding a From header but with PJSIP (which you will have to deal with down the road) doesn’t allow it. So your current setup will for sure not work as it isn’t RFC SIP compliant.
So yeah, I am trying to help by making sure you are understanding how things actually work and course correcting you for future proofing what you are doing. I’m sorry you didn’t like hearing that what you are doing is not proper but that just doesn’t change facts.
As you know, the macro is referenced on all outbound calls not just on DISA calls, so you must modify your dialplan to check the value of a channel variable in order to ensure that your changes are applied selectively. Adding DumpChan() to your dialplan will give you a list of variables, and if I rely on my awful memory, I recall there being one or more channel variables unique to DISA dialing that you can use for this purpose.
My preferred method of doing this is to use a spare line button on the phone as a “company B” line. This is simply a different extension that sends the company B caller ID. If any incoming company B calls are routed to this phone, I’d send them to the B extension, so the user can answer appropriately, callback from phone history works, etc.
Next choice would be an Outbound route with a special prefix that sends the company B number. For example, dial 99 followed by the number desired. (Replace 99 with something easy to remember that doesn’t conflict with your dial plan.)
Finally, if you really are stuck with DISA, fix the trunk setup so you can put the company B number in the caller ID field of the DISA module and it works!
That was a Excellent idea - Implemented and tested - works like a champ! I inherited the DISA from the people that installed it - got rid of it with this.