Search results

Believe it or not, I've tried doing the same things. The closest I've come is setting it to "Privacy: id" instead of "Privacy: none," but I haven't been able to remove it entirely.

Dialplan didn't work, and the Lua script didn't work even right before the call to the extension. It gets set when the INVITE is sent to the extension. It's not present anywhere before, so I can't actually override it anywhere. At this point, the only solution is to figure out why Freeswitch...

yeah, you will need to upgrade. That version is not even secure anymore.

There is a setting for that in the newest versions of FusinPBX. It's called voicemail instructions.

@whut It doesn't matter what device. The header is added for all external calls. Other devices ignore it, but this doorbell is a pain.

@Adrian Fretwell It's possible that my device has certain settings that are causing this behavior. However, I can't seem to figure out what the issue is. A Lua script didn't help either. The header is not there until the INVITE is sent.

@johnny Did you observe how much CPU it takes to run this locally by any chance? I'm curious because we can't afford to use all of the valuable CPU speed on AI and have the calls suffer from it. Does it take a lot to run?

That doesn't sound easy at all. A trunk between the two PBX is a start, and then a lot of routing must be implemented to have extensions talk to each other on both sides. You'd still have issues with many features because the two boxes are unlikely to play nicely with each other. An easier...

Maybe as easy as setting the Caller ID in E164 format?

I'm definitely adding this to FS PBX.

Fantastic! Here is my rtp_sdes_suites. But it's not a template. It may need some tweaking. AEAD_AES_256_GCM_8|AEAD_AES_128_GCM_8|AES_CM_256_HMAC_SHA1_80|AES_CM_192_HMAC_SHA1_80|AES_CM_128_HMAC_SHA1_80|AES_CM_256_HMAC_SHA1_32|AES_CM_192_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_32|AES_CM_128_NULL_AUTH

Akuvox doorbell. I'm now investigating how to remove the header using the LUA script. @Adrian Fretwell, the header is set after it hits the Freeswitch box. It's not coming from the PSTN.

I did some more extensive testing and must take my last post back. I found that I was originally correct in saying that my ring group is sending both media types in the invite, and the device decides which one to use. I do it because not all devices support SRTP and TLS. This is what it looks...

I was able to reproduce your issue. Ring Group stripped my SRTP media, too. I didn't do the test correctly the first time around, so it comes out as insecure media on the other side. It has to be the LUA script that does it unless I'm missing something, too. I'm going to play with it a bit to...

IMHO, The codec is unlikely the cause, or at least not the whole issue. You are sending insecure media, and the device is set to use TLS only with Compulsory mode. It would fail for sure at the negotiation step.

My test shows that I'm sending both secure and insecure media. So, the device can choose what they can use. v=0 o=FreeSWITCH 1724325946 1724325947 IN IP4 s=FreeSWITCH c=IN IP4 45.33.51.29 t=0 0 m=audio 22320 RTP/SAVP 0 9 8 102 101 13 103 104 a=rtpmap:0 PCMU/8000 a=rtpmap:9 G722/8000 a=rtpmap:8...

I'm going to test this on my server and get my hands on the Yealink phone in the next couple of days. I'll let you know what I find.

@mobi Before installing the FS PBX dashboard, you need to assign your user an email. Once you install the FS PBX dashboard, the email becomes the username, and your password stays the same. If you missed that step, you can modify the database directly and add an email to your user. You also need...

@mobi Did you do a new install? If so, the username and password were provided after FusionPBX installation before you installed the FS PBX dashboard. Check my full installation video.

Interesting post. rtp_secure_media=mandatory I didn't know that existed. Every day, you learn something new about Freeswitch. Would you please give it a try and let us know?