Hi all, I'm trying to build an Active/Active OpenSer 1.3 cluster with 2 nodes.
All it's working ok for the REGISTER messages throught the use of t_replicate and add_path, but I've problems with the INVITE messages.
Both servers share the same location table on a PostgreSQL Multimaster cluster (but that's irrelevant, the PostgreSQL cluster I mean...), using db_mode = 2
An that's the logic I used:
- On REGISTER ->>
- Auth Request - NAT ? - add_path - t_replicate(oser2)
- On INVITE ->>
- Auth Request - lookup - Load prefs from DB - relay
The problem I'm having is that the lookup function changes the RURI of the message on node1 BEFORE taking into account the "Path:" element present inside the AoR, so when the INVITE gets forwarded to node2 (where the NATed UAC it's registered), node2 deny the relaying of the message because $rD of the RURI it's not local (remember that the RURI whas changed on node1).
Is there any way to know on node1 that the INVITE request MUST obey the "Path:" so I could to something like:
$old_ru = $ru lookup("location") if(path_exists()) { $ru = $old_ru } ... t_relay()
??
Any other aproach ?
Best regards -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
Hello,
Raúl Alexis Betancor Santana wrote:
Hi all, I'm trying to build an Active/Active OpenSer 1.3 cluster with 2 nodes.
All it's working ok for the REGISTER messages throught the use of t_replicate and add_path, but I've problems with the INVITE messages.
Both servers share the same location table on a PostgreSQL Multimaster cluster (but that's irrelevant, the PostgreSQL cluster I mean...), using db_mode = 2
just out of curiosity: if you have DB multimaster replication in place, why do you replicate REGISTERs on SIP level as well?
Stefan
An that's the logic I used:
On REGISTER ->>
- Auth Request
- NAT ?
- add_path
- t_replicate(oser2)
On INVITE ->>
- Auth Request
- lookup
- Load prefs from DB
- relay
The problem I'm having is that the lookup function changes the RURI of the message on node1 BEFORE taking into account the "Path:" element present inside the AoR, so when the INVITE gets forwarded to node2 (where the NATed UAC it's registered), node2 deny the relaying of the message because $rD of the RURI it's not local (remember that the RURI whas changed on node1).
Is there any way to know on node1 that the INVITE request MUST obey the "Path:" so I could to something like:
$old_ru = $ru lookup("location") if(path_exists()) { $ru = $old_ru } ... t_relay()
??
Any other aproach ?
Best regards
Raúl Alexis Betancor Santana Dimensión Virtual S.L.
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Martes, 22 de Enero de 2008, Stefan Sayer escribió:
Hello,
Raúl Alexis Betancor Santana wrote:
Hi all, I'm trying to build an Active/Active OpenSer 1.3 cluster with 2 nodes.
All it's working ok for the REGISTER messages throught the use of t_replicate and add_path, but I've problems with the INVITE messages.
Both servers share the same location table on a PostgreSQL Multimaster cluster (but that's irrelevant, the PostgreSQL cluster I mean...),
using db_mode = 2
just out of curiosity: if you have DB multimaster replication in place, why do you replicate REGISTERs on SIP level as well?
Because "db_mode=2":
http://www.openser.org/docs/modules/1.3.x/usrloc.html#AEN285
2 - Write-Back scheme. This is a combination of previous two schemes. All changes are made to memory and database synchronization is done in the timer. The timer deletes all expired contacts and flushes all modified or new contacts to database. Use this scheme if you encounter high-load peaks and want them to process as fast as possible. The mode will not help at all if the load is high all the time. Also, latency of this mode is much lower than latency of mode 1, but slightly higher than latency of mode 0.
Hi Iñaki,
Iñaki Baz Castillo wrote:
El Martes, 22 de Enero de 2008, Stefan Sayer escribió:
Hello,
Raúl Alexis Betancor Santana wrote:
Hi all, I'm trying to build an Active/Active OpenSer 1.3 cluster with 2 nodes.
All it's working ok for the REGISTER messages throught the use of t_replicate and add_path, but I've problems with the INVITE messages.
Both servers share the same location table on a PostgreSQL Multimaster cluster (but that's irrelevant, the PostgreSQL cluster I mean...),
using db_mode = 2
just out of curiosity: if you have DB multimaster replication in place, why do you replicate REGISTERs on SIP level as well?
Because "db_mode=2":
http://www.openser.org/docs/modules/1.3.x/usrloc.html#AEN285
2 - Write-Back scheme. This is a combination of previous two schemes. All changes are made to memory and database synchronization is done in the timer. The timer deletes all expired contacts and flushes all modified or new contacts to database. Use this scheme if you encounter high-load peaks and want them to process as fast as possible. The mode will not help at all if the load is high all the time. Also, latency of this mode is much lower than latency of mode 1, but slightly higher than latency of mode 0.
thanks for the hint and link. but why not use db_mode 1 or better 3 and skip SIP REGISTER message replication with multimaster DB? is this too slow? to OP: do you have any numbers on postgresql multimaster replication performance? are you using pgcluster?
still puzzled Stefan