Ticket #1989 (closed Bugs: fixed)

Opened 5 years ago

Last modified 5 years ago

Long Lines Truncated in Trunks/Outgoing Settings/Peer Details

Reported by: middlebrook Assigned to:
Priority: minor Milestone: 2.3
Component: Core - Trunks/Routing Version: 2.3-branch
Keywords: line truncation trunks host= Cc:
Confirmation: SVN Revision (if applicable): 2.2.1
Backend Engine: Asterisk 1.2.x Backend Engine Version: Probably all

Description

This is a problem of configuration file lines being truncated by FreePBX, silently without any error or warning, at an unreasonably short line length. A good workaround would be to allow a syntax for continued lines. This probably applies in a lot more situations than the one described below.

So here is the background.

I used Voxbone for origination (DID provider) and they require 14 IP addresses for each of US and European locations. So, I set a

host=x.y.z.w&x.y.z.w&...

line in the Trunks/Outgoing Settings/Peer Details of FreePBX for Voxbone. The above line had the actual 14 IP addresses and it was truncated after about 11 of them with no error message at all. This is clear not good behaviour. Ideally, someone should increase the line length to something more reasonable or provide a way to enter multiple host= lines and have them concatenated would be even prettier.

Regards, Randall

Change History

06/12/07 09:20:07 changed by p_lindheimer

  • version changed from 2.2.2 to 2.3-branch.

r4052 - fixes for initial installs 2.2
r4053 - fixes for initial installs 2.3
r4054 - fixes for updates 2.3
r4055 - fixes for updates in 2.2.3 if we do one

For current system, the schema will have to be updated manually and it will fix this issue (at least up to varchar(255) which is the largest varchar supported by mysql 4.

Leaving open: TODO: put warning detection in 2.3 to detect strings that are too long so at least users know.

06/20/07 08:02:03 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to fixed.

I'm going to close this with the varchar(255) as the current fix and plan on going to a much larger varchar in a future release which will then require mysql5.0 or other sql versions that can handle larger varchars. For those versions, this coudld be set already.