mcbsys

Is it clear that the request is not about chatting amongst colleagues but about handling/forwarding inbound SMS from external people? There are lots of options for colleagues who want to chat with each other, including professional apps like Teams. I have one customer that uses QuickBooks chat in the office--someone showed them that once, it meets the need, so they keep using it. Phone app chat might be nice but there are alternatives. The need is for handling interactions with "outsiders" (customers, vendors, etc.) who randomly send text messages to the company phone number because they assume that every phone number in the world is capable of texting. This more clearly belongs in the PBX; the only alternative is to split voice from SMS and use separate software for the SMS.

I believe this request is about allowing groups to handle INbound SMS, a group chat so multiple PBX users can see and respond to messages coming in from outside. I believe 3CX shows the message to everyone in the group, then lets one user take ownership of the conversation. That lets you confirm that the SMS has been handled, but it would still be good if others could see and participate in the discussion (a supervisor wanting to jump in on a thread, for example).

My customer has a monthly subscription to Vodia, renewing on the 1st of each month. They've been running 68.0.32 on an Azure VM for several months without issues. This morning I came in to 142 emails from the phone system, one every minute or two since 4:37am: Subject: [Name] Phone System: Status change on trunk [Trunk Name] Body: Trunk . This is a notification email. Do not reply. Not a particularly informative message. When I logged in to the system (for the first time in weeks if not months), I was taken to the license page, which told me I have "No license" but an "Active subscription": I assume that the system was disconnected at this point (no trunk registration) but I didn't think to check. The Activation code in the screen was already correct. After I clicked Save, the License status changed to show the license: I received one more email with the message "[Trunk name] (2) changed to "200 OK" (1745 s)." What happened? Is this a Leap Year thing, not expecting a 29th of February? Is there a way to get an email when there is a license issue and not just hundreds of registration emails? Thank you.

You mean this? I had "Enable text messaging" set to "Set up in domain" (see my July 21 post above): but had not done further setup under Domain > Settings > General Settings > SMS Settings: In fact, I didn't even know that section exists inside the tenant--I just found it today by poking around. I don't think I've seen it in any docs, and the whole section disappears when you set Enable text messaging to On (which really means "Inherit from System"): I wonder what "Default" does and how it is different from "On" or "Off". Anyway with "Enable text messaging" set to On, I can send SMS from the tenant.

Yes, the log had timed out. I was thinking "1 hour" meant only keep the last hour... Just had to click Save to re-activate it. When sending SMS, I get "SMS provider unavailable", even after resetting the "Application secret" with the Telnyx API v1 Profile Secret. Messaging settings:

Thank you. I was able to receive an SMS, but when I replied from the Vodia app, the SMS did not go out. Did something change with logging? System Level > Status > Logfile is completely blank even though it is set up to keep 1000 events and all at level 9.

It's been several weeks now with SMS broken. What is the status of getting that fixed? Or is there some way to get it working with 68.0.30?

Thanks for thinking about it. The TLS trunk dropped twice today. I guess I’m giving up. I’ve never had these kinds of problems before, but I’ve never tried TLS before. I’ll change it back to UDP registered or maybe UDP with FQDN. I have to think that others have solved the persistent TCP connection issue. I’m setting up a Grandstream PBX appliance for another customer. It’s based on Asterisk. There are various keep-alive options, e.g. when setting up a registered UDP trunk, you can enable “heartbeat detection”: “If enabled, the PBX will regularly send SIP OPTIONS to check if the the device is online.” For (Grandstream) phones, you can set a policy: “Keep Alive Interval. Specify how often the phone will send a blank UDP packet to the SIP server to keep the ‘ping hole’ on the NAT router open.” Another example of persistent TCP is surveillance cameras. Synology Surveillance Station uses OPTIONS as the default keep-alive method. And what about site-to-site VPNs? They have to keep a TCP tunnel open… The best summary I’ve seen in the VoIP world is the article I cited earlier: https://www.asterisk.org/wanted-dead-or-alive/

I prefer not to run beta software especially on customer systems. Is there a way to subscribe to notifications for software releases?

Finally got another timeout. This time, when I started the trace, I disabled and re-enabled the trunk, hoping to force a handshake, which I guess Wireshark needs to be able to decrypt the traffic. Didn't work--all of the traffic before the timeout is encrypted. After the connection dropped and was re-established, I do see some decrypted SIP traffic, but I also see lots of encrypted traffic. Why would NAT not allow TCP connections on the fly? Isn't that what was working when I tested with a FQDN back at the beginning of this thread? The problem wasn't establishing the connection; the problem was that "Azure closes idle connections after 4 minutes without sending a TCP Reset (TCP RST) to let the other party know." But the idea of making a PBX like a bi-directional web server, allowing potentially dozens of short-lived connections... seems like that could bring its own issues. Here's the new trace. I don't see much different other than it got three FIN,ACKs instead of two, like it had a problem re-establishing the connection.

"Some confusion" about SMS configuration is an understatement! The message makes it sound like it's not set, so it will use the default of "true". Under Domain > Settings > Messaging > Notifications, I've got all the settings configured: The tenant is set to use the Default, so that should inherit from the domain, right? But then, what is the different between Default and Set up in domain? I tried On and Set up in domain for the tenant. Got a "Status change on trunk Telnyx" email on each change, but never got an SMS. The log message always says it's not enabled by default: ----> Tenant SMS set to "On" [9] 9:54:19.108 Tried to match recvsmsⓘ [8] 9:54:19.108 Receive SMSⓘ {"sms_id": "4ad14425-9033-4c26-8299-d50fd0cb279b", "direction": "inbound", "from": "+16191112222", "to": "+18583334444", "body": "SMS test 7"} [8] 9:54:19.108 SMS not enabled by default (setting=, default=true)ⓘ ----> Tenant SMS set to "Set up in domain" [9] 9:56:21.463 Tried to match recvsmsⓘ [8] 9:56:21.463 Receive SMSⓘ {"sms_id": "e3b236d4-c58b-4c77-82f9-7687396e5ad2", "direction": "inbound", "from": "+16191112222", "to": "+18583334444", "body": "SMS test 8"} [8] 9:56:21.463 SMS not enabled by default (setting=, default=true)ⓘ

No idea. Firewall seems unlikely--this is a pretty basic Linux machine running on Azure with no outbound restrictions, only inbound port forwarding. Also, I'm using the following command on that machine to capture the trace, which is logging "any" interface, so it should capture anything coming from the PBX, even if a firewall blocked something coming back to the PBX: sudo tcpdump -i any -nn '(host 192.76.120.10 or host 64.16.250.10)' -v -w telnyx.pcap The trace ran about 11 hours before the "FIN, ACK" was logged. If this is the correct Wireshark filter (also not an expert!), there are no pure FIN packets in the 11 hours preceding the "FIN, ACK": Unless of course Microsoft sent the FIN outside the machine because ... they wanted to reconnect the interface or something. I thought TCP would mean more stable connections for a PBX, with TLS a nice security bonus, but it seems to be just the opposite... TCP/TLS, at least as provided by Azure, reduces stability and reliability for long-running connections.

Customer just noticed that they are not receiving SMS, probably since the upgrade to 68.0.30 last week. Trying to deliver the SMS directly to an extension, which has ANI for SMS set to the customer's main number "(858) 333-4444" (number changed). Here's the log: [9] 12:39:25.412 Tried to match recvsmsⓘ [8] 12:39:25.412 Receive SMSⓘ {"sms_id": "be70e0b4-7482-41e5-a9f6-6d53ea1835b1", "direction": "inbound", "from": "+16191112222", "to": "+18583334444", "body": "Another test"} [8] 12:39:25.412 SMS not enabled by default (setting=, default=true)ⓘ [7] 12:39:25.412 Closing connection smtp.google.com:465ⓘ [9] 12:39:26.065 Message repetition, packet droppedⓘ [7] 12:39:26.065 Closing connection smtp.google.com:465ⓘ [9] 12:39:29.243 Last message repeated 2 timesⓘ [8] 12:39:29.243 Packet authenticated by transport layerⓘ [7] 12:39:30.071 Last message repeated 3 timesⓘ [9] 12:39:30.071 Message repetition, packet droppedⓘ [9] 12:39:30.300 Service flag 700: Use schedule 10:00-14:00ⓘ [9] 12:39:30.300 Service flag 700: Schedule 10:00-14:00 is set because 10:00 <= 12:39:30 <= 14:00ⓘ [8] 12:39:30.300 Service flag 700: Return positive trueⓘ Shouldn't it show SMS delivered? And what does the Service Flag schedule have to do with it? Also: the constant SMTP exchange with Google is very distracting when trying to read the logs. On one log page, "smtp.google.com" occurs 149 times even though not a single email is sent. Why?

According to https://ipwithease.com/what-is-tcp-fin-packet/: So it sounds like the FIN-ACK coming from Telnyx would be a reply (ACKnowledgement) to a FIN from the PBX. But I don't see the FIN. Maybe it was encrypted? I've had a trace running for three days, have captured 33,005 packets, but no timeout has occurred. I'm going to try to reset it now, and force a re-registration, which hopefully will capture the initial handshake.

I kept a tcpdump running most of the weekend, aborting and re-starting it every few hours when there was no registration failure. Finally this morning at 12:36am there was a 408 failure. Unfortunately even with the KEYLOGFILE, everything in the PCAP is encrypted until the re-registration at 12:38am. I assume this is because Wireshark needs the handshake to decrypt the following traffic? For some reason, even after the re-registration (and associated TLS handshake), much of the traffic is encrypted. However, just before the re-registration, I am able to see a FIN coming from Telnyx to the PBX, which seems to kick off the disconnect/reconnect/re-registration. There's plenty of traffic just before the FIN, so it wasn't a lack of traffic. Is it normal to get a FIN periodically? [Update a bit later: well really it's a FIN, ACK coming from Telnyx to the PBX. So does that mean the PBX sent a FIN first?] 10.2.0.4 is the internal IP of the PBX. 192.76.120.10 is sip.telnyx.com. Click for full size image.