The columns do exist in the database. The only route that kind of works is the incoming route. It will only save the ‘X-Twilio-CallSid’ header which is probably because it is sent with the initial request. I’m not able to save the ‘X-Twilio-RecordingSid’ header anywhere.
I’m so confused and I’ve spent way too much time trying to figure this out so I had to ask!
Modifying the FreePBX database is not recommended from the outset, so it’s doesn’t surprise me that you haven’t gotten a lot of support on this.
There are other databases for this information, including the real-time database in Asterisk and your own SIP_Headers tables in a MySQL database (Asterisk being the obvious choice).
I’m usually pretty good at figuring the “Why” and frankly, this request has me stumped. Why do you think you need to save the SIP headers? With a simple dial-plan change, you can get them into the /full log using a NoOP() and not have to save them for posterity. Explain why you want this stuff and maybe someone can come up with a simple, effective way to help you out.
I’m trying to figure out where I can save the headers sent with the final BYE 200 OK response between my freepbx box and Twilio’s SIP trunking service. So whenever a call hangs up on any Twilio trunked call (in and out), it logs all the headers in CDR for later use.
An example is I allow Twilio to store and manage call recordings. X-Twilio-RecordingSid allows me to construct a url for an mp3 audio stream of that recording. I can use that URL on our custom admin pages. I’ve also considered adding headers to SIP requests with our corporate firewall for logging.
you will see that the userfield and perhaps the peeraccount might work for you , but with a little thought you can “alter” the asteriskcdr table cdr to add what you want ion your custom dialplan and so insert as appropriate.
It is unlikely that FreePBX would remove that “altered” state on an “update” cos it would be hard to do on a working system. But you should add such fields to you [aliases] in /etc/asterisk/cdr_mysql.conf so you can for example
No matter what I did, I could not Noop the X-Twilio-CallSid header for outgoing calls. I decided to try and Noop the User-Agent and found that it was set as the SIP phone!?
So, what I found was that that immediately after the hangup handler runs, the final request takes place between Twilio and Freepbx.
I’m in the exact same boat, trying to get the CallSid from the X-Header on an outbound Twilio SIP trunk call in Asterisk. Did you ever get a solution? Twilio support said I should ask “Asterisk”. Heh.
It seems to me that we’ve worked out that Twilio doesn’t provide DID information on their “single user” connections. If there’s some other need you have, a SIP trace would be the first place to check, and once you’ve identified the part you want, we should be able to advise you.
Once you’ve “caught” them, what are you planning on doing with them?
There is an accountcode field that you can “divert” for this using a custom incoming context. You may (although I really recommend against it) add a couple of fields to the asteriskcdrdb/cdr table. You could also add a new “twilio” table that extends the CDR functionality by connecting the records by (for example) start date and time. Both of these likewise require custom context code.
I don’t think there’s anything from the GUI that’s going to help you, though. This is all “custom code” territory. If you have a budget, check with the Sangoma guys and see what they think,
I can store the X-Twilio-CallSID on INCOMING calls, but I can not get this to work with outbound calls at all.
Here is some additional information. We have a hangup handler set to execute on the conclusion of the calls. It is the same hand up handler for inbound and outbound calls. The handler is set to send debug information containing the X-Twilio-SID and X-Twilio-Recording-ID
There are three cases:
We make an outbound call. The debug information does not show either value
An inbound call and the called (internal) party hangs up. Debug shows the SID only.
An inbound call and the calling party (from the PSTN) hangs up. Debug shows both SID and Recording-ID values