On 15-08-2005 14:21, zkeatts wrote:
I think I have figured out why it would only accept
location or aliases as
a valid table.
Because there are only two tables in usrloc, location and aliases.
Location table stores the contacts of user agents, aliases implements
SIP URI alias mapping.
Doing a userloc.statistics returns to me those two
specific
table names listed as a member of domain.
Yes, internally location table is created in memory when you call
lookup("location"), aliases is created when you call
lookup("aliases")
somewhere in the configuration file.
Is it possible to add other tables under the accepted
domain structure?
Yes, but I am not sure if it makes any sense.
As for show_contacts I have run several more tests,
but I still have not
managed to get anything other than errors. I have manually added an entry
into locations with the following data
+-----------+--------+-------------------------+----------+---------------------+-------+-------------------------------------+------+---------------------+-----------+-------+-------+---------------------------------------+
| username | domain | contact | received | expires
| q | callid | cseq | last_modified
| replicate | state | flags | user_agent |
+-----------+--------+-------------------------+----------+---------------------+-------+-------------------------------------+------+---------------------+-----------+-------+-------+---------------------------------------+
| 271nv1001 | | sip:271nv1001@localhost | NULL | 2020-05-28
21:32:15 | -1.00 | 3653736-e3498618-a7aa0347@localhost | 42 | 2005-08-15
16:07:31 | 0 | 0 | 0 |
PolycomSoundPointIP-SPIP_500-UA/1.4.1 |
+-----------+--------+-------------------------+----------+---------------------+-------+-------------------------------------+------+---------------------+-----------+-------+-------+---------------------------------------+
I still get an AOR error when I try the following AOR's in my XML query.
<value><string>271nv1001</string></value>
<value><string>271nv1001@localhost</string></value>
<value><string>sip:271nv1001@localhost</string></value>
<value><string>3653736-e3498618-a7aa0347@localhost</string>
Those seem to be the only logical choices for the AOR. Why would it still
be returning an AOR not found?
I will get back to this later, I have to check the sources, it is
possible there is a bug.
Jan.