Summary: | ASTERISK-16501: [patch] use a realtime __options__ column to store several name=value pairs | ||
Reporter: | Walter Doekes (wdoekes) | Labels: | |
Date Opened: | 2010-08-04 07:56:42 | Date Closed: | 2010-08-04 09:01:28 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_realtime |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 20100804__issue17791.diff | |
Description: | Hi,
I'd like to add a special realtime column name named {{\_\_options\_\_}} that can hold several variables so I don't have to add a column to the table for every variable I might want to use someday. Example use: I have an {{asterisk_sipfriends}} table with a couple of columns: name, type, secret, host, ipaddr, port, nat. Now there is one particular host that needs the "{{session-timers=refuse}}" to be set. (In my case, an Alcatel box that lies about Supported: timer.) I really don't want to add a "{{session-timers}}" column to the {{asterisk_sipfriends}} table for two related reasons: (1) I just want to add an "advanced config" field to my peer configuration interface, not a specific session-timers option and (2) there might be some other option that is needed at some point that I can set through this "advanced config" string directly without having to alter the table again. h2. STEPS TO REPRODUCE With the attached patch, I can do this: {noformat} ALTER TABLE asterisk_sipfriends ADD COLUMN __options__ VARCHAR(255) DEFAULT ''; UPDATE asterisk_sipfriends SET __options__ = 'session-timers=refuse;session-expires=123;other-bogus-option=42' WHERE name = 'alcatel-box'; {noformat} Result: {noformat} voys-agilo*CLI> sip show peer alcatel-box load ... Sess-Timers : Refuse Sess-Refresh : uas Sess-Expires : 123 secs ... {noformat} h2. ADDITIONAL INFORMATION The attached patch is against 1.6.2.10. If required, I can create patches against SVN (1.6.2 and trunk). (And the documentation might need a bit of tweaking perhaps.) | ||
Comments: | By: Tilghman Lesher (tilghman) 2010-08-04 09:01:28 I understand your interest in this, but this is not a direction we want to take realtime architecture towards. Sorry. |