when doing a mysql ‘select’ the we receive the following values
mysql> select name, port, fullcontact, ipaddr from sip_buddies where name = '746';
+------+------+-----------------------------------------+--------------+
| name | port | fullcontact | ipaddr |
+------+------+-----------------------------------------+--------------+
| 746 | 5060 | sip:746@192.168.3.24:5060;transport=udp | 192.168.3.24 |
+------+------+-----------------------------------------+--------------+
1 row in set (0.00 sec)
They are correct. But when doing this with realtime the the it shows only the last seperated field from ‘fullcontact’ => “transport=udp” how can wen bring the hole string into a variable?
exten => 1773,n,REALTIME(sippeers|name|${number}|var_)
exten => 1773,n,Verbose(1,RealTime variable is '${var_port}')
exten => 1773,n,Verbose(1,RealTime variable is '${var_ipaddr}')
exten => 1773,n,Verbose(1,RealTime variable is '${var_useragent}')
exten => 1773,n,Verbose(1,RealTime variable is '${var_fullcontact}')
[May 20 21:42:49] VERBOSE[30623] logger.c: -- Executing [1773@fromsip:3] RealTime("DAHDI/11-1", "sippeers|name|746|var_") in new stack
[May 20 21:42:49] WARNING[30623] app_realtime.c: The RealTime application has been deprecated in favor of the REALTIME dialplan function.
[May 20 21:42:49] DEBUG[30623] res_config_mysql.c: MySQL RealTime: Everything is fine.
[May 20 21:42:49] DEBUG[30623] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_buddies WHERE name = '746'
[May 20 21:42:49] VERBOSE[30623] logger.c: -- Executing [1773@fromsip:4] Verbose("DAHDI/11-1", "1|RealTime variable containing data from the column field
is 5060") in new stack
[May 20 21:42:49] VERBOSE[30623] logger.c: RealTime variable is 5060
[May 20 21:42:49] VERBOSE[30623] logger.c: -- Executing [1773@fromsip:5] Verbose("DAHDI/11-1", "1|RealTime variable containing data from the column field
is 192.168.3.24") in new stack
[May 20 21:42:49] VERBOSE[30623] logger.c: RealTime variable containing data from the column field is 192.168.3.24
[May 20 21:42:49] VERBOSE[30623] logger.c: -- Executing [1773@fromsip:6] Verbose("DAHDI/11-1", "1|RealTime variable containing data from the column field
is ") in new stack
[May 20 21:42:49] VERBOSE[30623] logger.c: RealTime variable is
[May 20 21:42:49] VERBOSE[30623] logger.c: -- Executing [1773@fromsip:7] Verbose("DAHDI/11-1", "1|RealTime variable containing data from the column field
is transport=udp") in new stack
[May 20 21:42:49] VERBOSE[30623] logger.c: RealTime variable is transport=udp
I think your problem is that the Realtime dialplan function is for some reason using the semi-colon as a separator character.
Never seen that before.
However, I believe from what you have shown that you have all the information to reconstruct the field on the fly.
I may be wrong, but the fullcontact field is generated by Asterisk from other pieces of information anyways and it keeps it updated. So you would probably be safe reconstructing it from the other fields.
I just performed the same command on my system and it gave two fullcontact columns in the list just as yours did. However, I have been running this system in production for a long long time without any adverse affects.
For testing I put “;test” in the accountcode column on a user and the accountcode column was also duplicated for that user.
It’s not a mystery. The realtime function when getting the data for that row is using the semi-colon as a separator incorrectly. On that note, it still boggles my mind that Asterisk is not using XML/JSON everywhere to pass these data structures around instead of doing it the way they are. I cannot see it as having that much of an affect on performance.
If they don’t want to use that, the least they could do is to document it better, which would be deeply ironic since they themselves populate the fullcontact field and chose to put a separator in it like that
However, I don’t see it having an impact and if you really need to create a well formed fullcontact variable just use the following in your dialplan:
Now since you have two fullcontact columns I am betting that the ${var_fullcontact} is set to the “transport=udp” since it occurs last. So you may or may not be able to use it to get the transport type. So if you really have a mix of transport types just create another column in your database called transport_type and populate it.
You could then replace “tranport=udp” with ${var_transport_type}. I have tested custom fields in realtime and as long as there is data populating that column in the row, Asterisk will pick up the field and you can use it.
