Hello, Such a configuration is indeed possible. However, Asterisk and Kamailio are not interchangeable; Kamailio is a SIP proxy, and cannot offer the same in-channel and call supervision features that Asterisk can. So, the "survival mode" might be very simplified and basic compared to the caller experiences that Asterisk can provide. But it is possible. I don't know that it's the best architecture. You might instead investigate ways to make Asterisk more distributed and/or highly available. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

Hi João, I don't know that I can point you to a specific configuration. But I can elucidate some general principles: 1. Learn about and set these timers in the TM module configuration: https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.p.fr_timer https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tmp.p.fr_inv_timer If your logic for what constitutes a 'failure to respond' on the part of Asterisk is more complex or situational, there are also dynamic equivalents: https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.p.fr_timer_avp https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.p.fr_inv_timer_a… https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.f.t_set_fr https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.f.t_reset_fr It's safe to say that 'fr_timer' is the one you really care about. 2. When contacting Asterisk, use t_relay(). Prior to t_relay(), arm a failure_route: request_route { ... if(method == "INVITE") { ... t_on_failure("ASTERISK_FAILOVER"); if(!t_relay()) sl_reply_error(); exit; } ... } 3. The failure_route is called when any negative reply is received, or when a timeout occurs. Depending on how you choose to define 'fails to respond', you will need to have some logic in the failure_route to account for this: failure_route[ASTERISK_FAILOVER] { if(t_is_canceled()) exit; # The actual timeout case. if(t_branch_timeout()) { # Do a local registrar lookup instead. if(!lookup("location")) { send_reply("404", "Not Found"); exit; } } ... } 4. To allow Kamailio to know how to reach other extensions, you need a kind of "middlebox" or "shadow registrar" on the Kamailio side, even if the primary source of truth for the location database is the upstream Asterisk. There are several ways to accomplish this. One is to do a silent local save() and relay the registration upstream: if(method == "REGISTER") { save("0x06"); # probably should check for errors $du = "sip:asterisk_ip:5060"; if(!t_relay()) sl_reply_error(); exit; } Or perhaps you might prefer to use t_replicate() to share the registration with Asterisk more crudely. That depends on a number of other factors. And, of course, if you're in the path of registrations relayed upstream to Asterisk, you'll need to use Path (if the version of Asterisk you are using upstream supports it[1]), or set an `outbound_proxy` value on the chan_pjsip peer for the proxy. I think you can understand why building an entire configuration for you is not a simple task, but hopefully these pointers should get you moving in the right direction. Feel free to ask further specific questions if you run into stumbling blocks! Boa sorte! -- Alex [1] https://www.mail-archive.com/sr-users@lists.kamailio.org/msg18644.html -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800