Hello,
I have a setup with 2 kamailio in active/idle, locations are shared via
dmq_usrloc, but database is also used as a cache where other systems can
access and query "real-time" data.
The config we have is:
# ----- usrloc params -----
modparam("usrloc", "db_url", DBURL)
modparam("usrloc", "db_mode", 1)
modparam("usrloc", "db_load", 0)
modparam("usrloc", "db_insert_update", 1)
modparam("usrloc", "db_timer_clean", 1)
modparam("usrloc", "server_id_filter", 1)
modparam("usrloc", "timer_procs", 2)
modparam("usrloc", "timer_interval", 60)
# ----- dmq_usrloc params -----
modparam("dmq_usrloc", "enable", 1)
modparam("dmq_usrloc", "sync", 1)
modparam("dmq_usrloc", "batch_msg_contacts", 50) # 50 contacts / message
modparam("dmq_usrloc", "batch_size", 10000) # 10000 contacts / batch
modparam("dmq_usrloc", "batch_usleep", 500000) # one batch every 500ms
With this setup, we assume:
1- almost real-time updated location info in the database.
2- as long as one of the two Kam is up, location information will not be
lost (as they will sync with each other via DMQ)
3- if both servers go down, locations are lost (as they will not reload
from database on startup).
Our tests work well with the above config, with one exception, on the idle
node, we see a lot of (only happens on the node receiving location via dmq):
Feb 21 00:11:25 csbc02 csbc[13916]: ERROR: <core> [db.c:481]:
db_use_table(): invalid parameter value
Feb 21 00:11:25 csbc02 csbc[13916]: ERROR: usrloc [ucontact.c:1136]:
db_update_ucontact_ruid(): sql use_table failed
Feb 21 00:11:25 csbc02 csbc[13916]: ERROR: usrloc [ucontact.c:1657]:
update_contact_db(): failed to update database
I added debug logs to see if I could understand the reason:
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:478]:
usrloc_dmq_handle_msg(): dmq message received from
sip:usrloc@10.2.1.181:5050
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:423]:
usrloc_dmq_execute_action(): Received DMQ_UPDATE. Update contact info...
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:75]:
add_contact(): aor: 1063362
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:76]:
add_contact(): ci->ruid: uloc-1-5e502cd3-5629-1
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:77]:
add_contact(): aorhash: 928261667
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:115]:
add_contact(): '1063362' Not found in usrloc
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:117]:
add_contact(): Insert record
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: usrloc [ul_callback.h:83]:
run_ul_callbacks(): contact=0x7fe41ff41f40, callback type 1/15, id 0 entered
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:800]:
dmq_ul_cb_contact(): Callback from usrloc with type=1
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:826]:
dmq_ul_cb_contact(): Contact received from DMQ... skip
Feb 21 14:38:34 csbc02 csbc[30796]: ERROR: <core> [db.c:481]:
db_use_table(): invalid parameter value
Feb 21 14:38:34 csbc02 csbc[30796]: ERROR: usrloc [ucontact.c:669]:
db_insert_ucontact(): sql use_table failed
Feb 21 14:38:34 csbc02 csbc[30796]: ERROR: usrloc [urecord.c:598]:
insert_ucontact(): failed to insert in database
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:121]:
add_contact(): Insert ucontact
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:124]:
add_contact(): Release record
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: dmq_usrloc [usrloc_sync.c:126]:
add_contact(): Unlock udomain
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: sl [sl.c:305]: send_reply():
reply in stateless mode (sl)
Feb 21 14:38:34 csbc02 csbc[30796]: DEBUG: <core>
[core/msg_translator.c:161]: check_via_address(): (10.2.1.181, 10.2.1.181,
0)
Can anyone help me understand what's the problem? I have the server_id
setting, and the modparam server_id_filter, so shouldn't the receiving node
just ignore any database tasks?
Thanks,
Joel.
Hi,
We are fighting with a vendor and trying to explain to them that call
routing should be based on the RURI on the INVITE and *not* the To header.
I went through RFC 3261 and while there are many "indicators" and it seems
like its screaming that we should be using the RURI, is anyone aware of any
specific text (that I may have missed) where it says specifically call
routing should be done based on the RURI and *NOT* the to header?
TIA.
Dovid
https://tools.ietf.org/html/rfc3261#page-78
1) 8.1.1.1 Request-URI
*The initial Request-URI of the message SHOULD be set to the value of the
URI in the To field.* - Note that it says SHOULD but is NOT mandatory. Also
this is for the *INITIAL* request.
*This may or may not be the ultimate recipient of the request.* - Again
this is the To field. The RURI is what we are supposed to follow when we
want to know where the call should be delivered to.
2) 8.1.2 Sending the Request
-Usage of the URI from the *To and From fields in the original request
within subsequent requests is done for backwards compatibility with RFC
2543*, which used the URI for dialog identification. *In this
specification, only the tags are used for dialog identification*. It is
expected that mandatory reflection of the original To and From URI in
mid-dialog requests will be deprecated in a subsequent revision of this
specification. - While this is for subsequent requests (and not an original
one) you see that the only point of the To field is to identify the dialog.
3) 8.2.2.1 To and Request-URI
The To header field identifies the *original recipient of the request*
designated by the user identified in the From field. - Note that the TO
field identifies the ORIGINAL recipient, this **CAN** change. This is
basically telling you that you *can't* rely on the To header for routing.
*However, the Request-URI identifies the UAS that is to process the request*.
- As you can see the Request-RU and *NOT* the TO header tells you where the
request should go.
5) 12.2.1.1 Generating the Request
a. The UAC uses the *remote target* and route set to build the *Request-URI
and Route header field of the request*. - This is self explanatory. it
shows that the RURI is using for routing and *NOT* the to header.
b. The procedures in Section 8.1.2 will normally result in the request
being *sent to the address* indicated by the topmost Route header field
value or the *Request-URI* if no Route header field is present. Subject to
certain restrictions, they allow the request to be sent to an alternate
address (such as a default outbound proxy not represented in the route
set). Again self explanatory.
6) 16.5 Determining Request Targets
Each target in the set is *represented as a URI*. - This clearly shows that
how we route is based on the RURI and *NOT* the to header.
7) 26.5 Privacy
Thus it MAY be desirable for privacy reasons to create a To header field
that differs from the Request-URI. - Again this shows that the to may not
match up the RURI. Think of the To header as the contact in someones phone
and the RURI as where we are calling. The to header may be bob(a)1.1.1.1 but
the URI is where we are actually calling which is 12346(a)1.1.1.1 or
bob_smith(a)1.1.1.1.1
Hello, I'm using presence and pua modules, it works perfectly when username
is equal to extension...
But now I have case when username is not equal to the extension..
Like:
extension: 1111
username: aythnbghhgt
How I can implement this? Any ideas?
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Hello, I'm using presence and pua modules, it works perfectly when username
is equal to extension...
But now I have case when username is not equal to the extension..
Like:
extension: 1111
username: aythnbghhgt
How I can implement this? Any ideas?
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Hello,
I have an installation using usrloc + db_mode=1.
If I want on db_mode=1 or db_mode=2 the expired contacts to be cleaned up I
have to enable the modparam db_timer_clean:
https://www.kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.db…
The docs say:
"*Enable (1) or disable (0) cleaning of expired db records on timer basis
for db_mode WRITE-BACK and WRITE-THROUGH. It uses the secondary timer
process.*"
I have the following doubts:
1- What does the reference "it uses *the* secondary timer process" mean? Is
there a specific secondary timer just for this purpose?
2- Is #1 related to the modparam timer_procs? (so it uses one of those
when enabled?)
3- Why/When would you need a timer_proces modparam with a value higher than
"1"?
Thanks,
Joel.
Hi Guys,
I have a quick question wondered if anyone could provide some suggestions please?!
We have a setup of two registrars in EC2 (kamailio 4.4 running on debian VMs) which act in an active/active fashion with a number of devices
behind NAT where we use the DMQ dmq_t_replicate function to send the registration details between each server and append the PATH parameter
so the registrar the device registered with is always associated with the client device.
This all works fine, the only issue is persistency should we have a failure of one of the registrars, be it process or server and recovering the correct
PATH detail so the end device can still be reached.
I have tried this with separate databases with each registrar, which works when using cache and db but I ideally want the same database for the two servers and not
change the architecture at this time unless it is a necessary.
I have also tested with dmq_usrloc but this again provides the usrlocation details of the notification servers in the group(not path), again which I understand but I wondered
if there is anything else I could try or its just a question of in the event of a failure half the registrations will be effected until it recovers and they
re-register again if I dont want to have separate databases (location tables) or I add more network elements into the flow, such as HA pair or load balancer but just want to
make sure I have exhausted all options or consider the risk before I look to do this.
Many thanks!
Jon
Hi All,
I'm facing an issue with the third party registration in the ISC interface
between the SCSCF and the AS.
The AS is triggered for deregistration but not for registration.
Attached are logs for a register that not works and a deregister that works
Regards
Lanvin ADON