| Summary: | ASTERISK-11827: gratuitous, incorrect database lookups when loading a realtime SIP peer/user | ||
| Reporter: | Brent Thomson (_brent_) | Labels: | |
| Date Opened: | 2008-04-10 18:32:39 | Date Closed: | 2011-06-07 14:07:58 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_config_pgsql |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) asterisk-output.txt ( 1) postgresql-output.txt | |
| Description: | With debugging turned way up, I noticed a warning in the CLI when placing a call between two extensions on an instance of Asterisk (my sippeers/sipusers table is user_agent_client_assignment): [Apr 10 23:36:00] WARNING[32014] res_config_pgsql.c: Postgresql RealTime: Could not find any rows in table user_agent_client_assignment. Examining the PostgreSQL logs and more Asterisk debugging shows that Asterisk makes one correct, successful query and several badly-formed, unsuccessful queries. See the attachments for output from Asterisk and PostgreSQL. | ||
| Comments: | By: Brent Thomson (_brent_) 2008-04-10 18:37:56 Oh, and the badly-formed queries are using the call ID, rather than the SIP username as the basis of the search for the SIP user. On further investigation, it also appears that the correct query I was seeing was as the UA was authenticating prior to making the call. Both log files show one complete (although unanswered) call--dial, ring, hangup. The call completes just fine in spite of the errors. By: P. Christeas (xrg) 2008-04-11 02:39:58 The messages are harmless (except the increased SQL load). see at main/devicestate.c:323 the explanation. By: P. Christeas (xrg) 2008-04-11 02:41:03 Also check ASTERISK-9385 By: Tilghman Lesher (tilghman) 2008-04-11 10:12:11 No, those queries are correct. You're simply seeing the order in which Asterisk tries to do matching. We try to keep the behavior identical, in terms of matching, whether you're using static or realtime configs. | ||