Inconsistent Trunk Logic V68 vs V69

[Vernon]

Hello,

I've been testing V69 and when i created the trunk configuration that worked in V68, it surprisingly fails on V69.

So far the biggest contributing factor that i can find is that when the trunk is setup with "Rewrite Global Numbers" to Use + Symbol at beginning. V69 interprets this to modify inbound numbers as well.

 

So lets say i have an inbound DID: 7854561234. This DID is on V68, i update to V69 with my V68 trunk configuration, and the calls will begin to fail consistently.

From what i can see (the logs are very sparse for some reason), the PBX is expecting +7854561234, irrelevant if the country code is set or not, it only changes how the DID is presented on the interface.

When i manually add an extra did as 0117854561234, inbound will begin to work.

As soon as i downgrade the PBX back to V68, no issues whatsoever. I went over the release notes trying to see if a new setting or option was introduced into the trunking, but nothing sticks out. There appears to be undocumented changes (format is different of trunks when viewing in text view).

 

Based on my findings perhaps the best course of action is to revert the logic change, and then introduce a new setting/feature in the trunk that edits/rewrites INBOUND numbers. It would definitely help other users with similar setups to cut down on spending support time trying to figure out what went wrong during the update.

[Vodia PBX]

Unfortunately, the number presentation in SIP trunks is a mess. The world would be easier if every SIP trunk just uses the format starting with the +. We even have some trunk providers that don't have the same format in the Request-URI and the From/To-headers!

For outbound calls, there is a lot of control over the presentation by choosing the right headers. There is a large selection of variables in various formats to tweak it the right way. You can actually see them in the log when you turn TRUNK log to level 9. Then the number presentation setting of the trunk does not matter.

For inbound calls, the trunk number presentation setting is important. There is some tolerance, e.g. as soon as the PBX knows that the number is in the NAPPA area it does not matter if the call comes in as 10-digit or 11-digit domestic number. 

We try to maintain the trunk list to handle this all without the admins having to worry too much about it. If you set up your own trunk provider, well, it does take some tweaking. We are glad to add other providers if you want to share your trunk settings. 

[Vernon]

I test it by routing calls through a switch where the trunk is a gateway, but my trouble is not the provider settings but the unknown changes. It makes a big difference for multi-tenant PBX's because fixing one trunk is easy. Fixing 200 is quite an undertaking.

 

As an example, you have your front door, you have your one key, you live on V68 Avenue Road, and everything just works without any issues or changes. You decide one day to upgrade your home lifestyle and go down to V69 Street, you take with you to your new house, yourself, your door, and your key that you know works for this door. But to your dismay your key now no longer works when the door is installed on V69 Street.

The text view is also a lot nicer now, before all the text values were all over the place, but with V69 the format automatically changes that the most important values are up top and the generics are at the bottom. This is a nice addition.

I will definitely review the logs a little more closely the second time around and see if there's an easy/fast change that can be made to accommodate the transition from v68 to v69

[Vodia PBX]

On 11/17/2023 at 5:11 PM, Vernon said:

Fixing 200 is quite an undertaking.

I agree. Personally, I would probably write some bash/curl script that does the necessary changes.

We don't do these changes usually for some reason. As for SRTP stuff, we figured that the relative number is still small (sadly) and we better get it done sooner than later. The old SRTP was simply not following the RFC, and it was better to fix this now.