<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 30 Jun 2021, at 09:10, Shahid Hussain <<a href="mailto:shnx88@gmail.com" class="">shnx88@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<br class="">Websocket module documentation has a code reference to use aliases for SIP routing. However, aliases will not work in the following setup and situation.<br class="">1. Kamailio is configured with active and standby node<br class="">2. Ping is implemented from webclient and kamailio responds with pong.<div class="">3. Two clients ClinetA and ClientB registered themselves to Kamailio.<br class="">4. After SIP negotiation (INVITE-200OK) each client learnt about below aliases.<br class="">Alias of ClientA:<br class="">alias=172.27.6.98~58336<br class="">Alias of ClientB:<br class="">alias=172.27.6.98~58342<br class=""> <br class="">So normally if ClientB wants to send SIP message to ClientA, SIP URI from ClientB looks like below<br class="">ACK <a href="sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws" class="">sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws</a> SIP/2.0<br class=""> 4. Call is in a connected state.<div class=""><br class="">Following is the issue.<br class="">i.  Switchover (or network lost or reboot) at Kamailio happened</div><div class="">ii.  Due to ping pong both the clients detected network loss individually and re-registered themselves.<br class="">iii.  Aliases of both the clients got changed.<br class="">New Alias of ClientA:<br class="">alias=172.27.6.98~ 58346<br class=""> <br class="">New Alias of ClientB:<br class="">alias=172.27.6.98~ 58348<br class=""> <br class="">iv.   But ClientB doesn’t know that ClientA also re-registered and ClientA’s alias got changed and vice-versa<br class="">v.    Because of this ClientB still sends BYE with Initial alias<br class="">BYE <a href="sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws" class="">sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws</a> SIP/2.0<br class=""><br class="">Would like to know what is the recommended solution for this problem using alias or is it a limitation of using alias?<br class=""></div></div></div></div></blockquote></div><br class=""><div class="">Full implementation of SIP outbound is the only solution close to solving this problem in the IETF standards.</div><div class="">However, I have seen no single SIP client that have implemented this, even though Kamailio supports</div><div class="">it on the server side. The idea is that you always have two TCP connections to two active servers.</div><div class=""><br class=""></div><div class=""><a href="https://datatracker.ietf.org/doc/rfc5626/" class="">https://datatracker.ietf.org/doc/rfc5626/</a></div><div class=""><br class=""></div><div class="">Having said that, SIP outbound enables registration survival and always being reachable, but it does not handle dialog survival. It was something we discussed for a while at the latest Kamailio dev meeting.</div><div class=""><br class=""></div><div class="">Hopefully the actual RTP streams can survive the failover and the call can go on, but if it depends on SIP signalling there’s no other way (that i know of) to survive and move the call to a new server with a new TCP connection. I have struggled with similar problems and made possible call survival in the case of lost SIP signalling path. It requires SIP uas that doesn’t implement any keepalive or SIP timer that will hangup if SIP signalling is dead.</div><div class=""><br class=""></div><div class="">/O</div></body></html>