<div dir="ltr"><div>Hi Folks,<br></div><div><br>Just found another simple use case of the dispatcher latency stats.<br><br></div>Just shraing this idea of a feature I want to contribute.<br><div><br>When using dispatcher algorithm 8:<br><br>   “8” - select destination sorted by priority attribute value (serial forking ordered by priority).<br><br>If the gateway as the attribute, the priority becomes the estimated latency.<br><br>   cc-priority<br><div><br></div><div>- The dispatcher would automatically prioritize the closest one.</div><div>- If a gateway is becoming unresponsive it will automatically become de prioritize.<br></div><br>Consider this real life scenario where you have gateways in East and West Coast </div><div>Example <br></div><div><br>URI: sip:28.71.19.140                                                                                                                                                                                       <br>FLAGS: AP<br>PRIORITY: 10<br>ATTRS: {<br>        BODY: cc_priority=1<br>}<br>LATENCY: {<br>        AVG: 84.001000<br>        STD: 0.062000<br>        EST: 84.001000 (high == low priority)<br>        MAX: 93<br>        TIMEOUT: 0<br>URI: sip:28.71.16.140<br>FLAGS: AP<br>PRIORITY: 10</div><div>ATTRS: {<br>        BODY: cc_priority=1<br>}</div><div>LATENCY: {<br>        AVG: 29.110000<br>        STD: 2.383000<br>        EST: 31.999000  (low == high priority)<br>        MAX: 1499<br>        TIMEOUT: 1</div><div><br></div><div><br></div><div>Another major improvement to all of this would be to gather stats on INVITE <> 100 to have a very accurate latency estimation even if the gateway does not support SIP OPTIONS pings<br></div><div><br></div><div><br></div></div>