Merge pull request #247893 from boris-bazilevskiy/doc-update-0823

update SIP OPTIONS logic

Author: ttorble

articles/communication-services/concepts/media/monitoring-troubleshooting-telephony/sip-options-config-routing.png

@@ -26,7 +26,34 @@ Microsoft is working on providing more tools for troubleshooting and monitoring.
 
 ## Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) OPTIONS messages
 
-Azure Communication Services direct routing uses SIP OPTIONS sent by the Session Border Controller to monitor SBC health. There are no actions required from the Azure administrator to enable the SIP OPTIONS monitoring. 
+Azure Communication Services direct routing uses SIP OPTIONS sent by the Session Border Controller to monitor SBC health. There are no actions required from the Azure administrator to enable the SIP OPTIONS monitoring. The collected information is taken into consideration when routing decisions are made.
+
+For example, if there are several SBCs available to route a call, direct routing considers the SIP OPTIONS information received from each SBC to determine routing.
+
+Here's an example of the configuration:
+
+![[Screenshot showing SIP options configuration example.](../../media/monitoring-troubleshooting-telephony/sip-options-config-routing.png)](../../media/monitoring-troubleshooting-telephony/sip-options-config-routing.png#lightbox)
+
+When an Azure Communication Services SDK app makes a call to number +1 425 \<any seven digits>, direct routing evaluates the route. There are two SBCs in the route: `sbc.contoso.com` and `sbc2.contoso.com`. Both SBCs have equal priority in the route. Before picking an SBC, the routing mechanism evaluates the health of each SBC, based on when the SBC sent the SIP OPTIONS last time.
+
+An SBC is considered healthy if statistics at the moment of sending the call shows that the SBC sends OPTIONS every minute.  
+
+When a call is made, the following logic applies:
+
+- The SBC was paired at 10:00 AM.  
+- The SBC sends OPTIONS at 10:01 AM, 10:02 AM, and so on.  
+- At 10:15, a user makes a call and the routing mechanism selects this SBC.
+
+Direct routing takes the regular interval OPTIONS three times (the regular interval is one minute). If OPTIONS were sent during the last three minutes, the SBC is considered healthy.
+
+If the SBC in the example sent OPTIONS at any period between 11:12 AM and 11:15 AM (the time the call was made), it's considered healthy. If not, the SBC is demoted from the route.
+
+Demotion means that the SBC isn't tried first. For example, we have `sbc.contoso.com` and `sbc2.contoso.com` with equal priority in the same voice route.  
+
+If `sbc.contoso.com` doesn't send SIP OPTIONS on a regular interval as previously described, it's demoted. Next, `sbc2.contoso.com` tries for the call. If `sbc2.contoso.com` can't deliver the call because of the error codes 408, 503, or 504, the `sbc.contoso.com` (demoted) is tried again before a failure is generated. 
+If both `sbc.contoso.com` and `sbc2.contoso.com` don't send OPTIONS, direct routing tries to place a call to both anyway, and then `sbc3.contoso.com` is tried.
+
+If two (or more) SBCs in one route are considered healthy and equal, Fisher-Yates shuffle is applied to distribute the calls between the SBCs.
 
 ## Monitor with Azure portal and SBC logs