12/20/2016 – Updated to include alternate IP-to-IP Routing configuration

SIP OPTIONS requests are a crucial piece of functionality for Lync/Skype4B deployments, but even so, OPTIONS requests are utilized within other Unified Communications platforms as well.  OPTIONS requests are most commonly used as a keepalive mechanism between SIP-based systems to determine if the remote end is ‘alive’.  For many of the IT Admins out there, you’ll recognize this as the difference between performing a TCP test on Port 80:


vs. ensuring an HTTP 200 OK is returned to an HTTP GET request to the same server:


The difference is critical:  just because a port is open or a TCP connect completes, doesn’t mean the application on the remote end utilizing that port is actually functional.  In the above scenario, our web server may be functional but perhaps the IIS Application Pool isn’t running and as a result, HTTP 500 errors are being generated thus taking an e-commerce website offline.  Not good!

For most environments you’ll see monitoring systems and hardware load balancers configured for this additional in-depth configuration, but OPTIONS requests are the equivalent in the SIP world of this more advanced monitoring capability.  Despite this common keepalive usage, OPTIONS requests as per RFC 3261 can actually be utilized to obtain much more:

The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method.

Want to know what codecs are supported by the remote endpoint?  Check.

Note:  You typically don’t see codecs listed in most OPTIONS requests but the capability does exist within the RFC to handle it.

Want to know what content types are supported by the remote endpoint?  Check.

Bottom line:  OPTIONS requests are your baseline heartbeat for SIP user agents.  If a OPTIONS request isn’t responded to by the remote UAS, then the UA believes the remote UAS is ‘down’ and must attempt to re-route requests to another remote UAS.

Where Skype4B Fits In

Mediation Servers in Skype4B send OPTIONS requests to all Trunks defined in Topology, which means that each Mediation Pool is checking each PSTN Gateway for status.  If SIP OPTIONS requests are not processed by the PSTN Gateway then Skype4B thinks the trunk is down and won’t attempt to route calls to it.  After all, why attempt to route a call somewhere when it may be down? In turn, the SBC typically maintains status of the remote endpoints within its configuration, such as a upstream Cisco Call Manager cluster:


So long as OPTIONS requests are processed by all endpoints, calls should flow without issue.  Even so, a potentially outage inducing scenario exists if you aren’t prescriptive in your configuration…

The Audiocodes Specifics

When you look at most of the Audiocodes guides out there, you’ll notice that they don’t typically outline what is required to properly handle OPTIONS requests.  In most general documentation, you see a more ‘*‘ approach whereby all messages from Skype are simply forwarded to a remote system without much thought:


What the rule above shows is that if any type of SIP request (Request Type=All) comes from the Skype4B Mediation Servers (Source IP Group), the message is to be routed to a remote SBC (Destination IP Group).  This is all fine and dandy – and will likely result in calls that function – but there’s a very dirty secret:  it results in OPTIONS messages being routed to the remote endpoint as well.  Instead of the SBC terminating the OPTIONS message from Skype4B, the OPTIONS message gets passed along to the remote endpoint (say CUCM, for example) and the Audiocodes SBC won’t report back status to Skype4B until it hears back from CUCM.  In effect, your OPTIONS status from Skype4B to the SBC becomes dependent upon the successful completion of the OPTIONS status being reported by another remote system upstream (CUCM, for example) as a result of the routing rule configuration.

Take my advice:  don’t use the approach above!

The correct way to handle this would be to ensure that the Audiocodes SBC is configured so that it locally handles OPTIONS messages.  Instead of passing OPTIONS requests along to a remote system for a downstream system, you want the SBC to handle each OPTIONS request locally, thus ensuring an independent view of status from the perspective of the SBC and for each connected remote system.

For each system the SBC is interacting with, you need to define an IP-to-IP routing rule that resides at the very top of your rule list:


There are a few critical differences in this rule:

  • Request Type = OPTIONS
  • Destination Type = Dest Address
  • Destination Address = internal

With this rule in place, the SBC locally handles the OPTIONS request from Skype4B and immediately reports back its own status back to Skype4B.  It does not pass the message along to an upstream system (CUCM, for example).  And yes, you need to have as many of these rules as you have SIP systems sending OPTIONS requests to the Audiocodes SBC.

12/20/2016 Update

Note: Another configuration is possible.  Instead of creating an IP-to-IP rule for each IP Group (potentially resulting in tens or hundreds of rules), you can essentially create a “catch all” rule that allows a single IP-to-IP rule to handle receiving OPTIONS requests.  Using the same base format as the rule above, you simply need to change the Source IP Group so that it is ‘Any’:


This rule will function exactly the same and allow the SBC to locally handle OPTIONS requests.  The big difference is that this rule will allow any IP Group defined in the SBC to be responded to all while using a single rule instead of defining individual rules for each IP Group in the configuration.  Personally, I would define an IP-to-IP rule per IP Group but choose the configuration that suits you best.

As a result of this rule, the flow changes dramatically and the SBC processes the request locally:


The syslog entries show additional detail of the SBC processing the OPTIONS request locally:


Moral of the Story

When configuring Audiocodes SBC’s, make sure you have specific IP-to-IP routing rules defined using above as a basis for properly handling SIP OPTIONS messages.  There are a few Audiocodes documents out there that have these settings defined, but many of the Lync/Skype4B related documents seem to be absent this info.  It seems counter intuitive that you’d have to define special rules for OPTIONS requests, but given that the SBC is flexible enough to actually route OPTIONS messages at all, it does make some logical sense.  An OPTIONS message is still a SIP message, so just remember the extra steps required to properly configure an Audiocodes SBC to handle the messages.

As a final note, this type of logic doesn’t seem to exist in the Audiocodes gateway code.  In that scenario, the OPTIONS requests seem to just ‘automatically handled’ and additional configuration isn’t required.  IMHO, it seems that the SBC code is the truly first place this became a requirement.

3 thoughts on “Handling SIP OPTIONS Requests on Audiocodes SBCs

  1. Can you please clarify why you don’t want the SIP options request to be forwarded to the downstream SBC? In my experience this can result in outbound call failures. For example, if your primary SIP trunk is down the AudioCodes SBC will still respond to the SIP options request from Lync/SfB and it will NOT be marked as down. If you forward the SIP options request to the downstream SBC and it cannot respond, Lync/SfB will mark the gateway as down and can route the calls to another SBC, provided you have another route.

    1. It all depends on the scenario, I suppose. Personally speaking, I believe OPTIONS pings should be independent for each system connected to the SBC. OPTIONS pings are meant to obtain the status of the next hop; not daisy chain them together for downstream systems. I don’t want a Skype4B trunk to be dependent on the success of an OPTIONS ping to Cisco when there may be alternate routes via the SBC.

      Consider: say your Audiocodes SBC has three paths for outbound calls – CUCM, AT&T, and Verizon. You could, in this scenario, have a single trunk in topology from Skype4B to the SBC and simply let the SBC handle routing to the various carriers. If you blindly forward ‘*’ to CUCM as the first routing rule in the SBC, you’re now dependent upon OPTIONS requests always working for CUCM. If, for any reason, CUCM goes down and the other two providers don’t support OPTIONS pings, then Skype4B stops getting OPTIONS replies and marks the entire trunk to the SBC as down. As a result of Skype4B marking the entire trunk as down, you now cannot get calls to the alternate routes on the SBC due to the lack of other rules in place to handle an inbound OPTIONS request from Skype4B.

      In all honestly, the real answer is it all depends on your routing configuration and what the other carriers potentially support, but I would rather that each leg of the journey (Skype4B to SBC/SBC to Skype4B, SBC to CUCM/CUCM to SBC, SBC to AT&T/AT&T to SBC, SBC to Verizon/Verizon to SBC) be independent and unique. This includes the way I handle OPTIONS messages, as well, because SIP error messages are different when a call fails due to OPTIONS not working VS a carrier issue that might result in a 504 or 503.

      1. In my scenario, we have a single SIP trunk and AudioCodes SBC at the corporate office and another SIP trunk and AudioCodes SBC at a branch office. If the SIP trunk fails at corporate, I want outbound calls to route over the WAN to the branch. Since I don’t have multiple PSTN connections on the corporate SBC, it makes sense to me to forward the SIP options request through to the upstream SBC.

        Thank you for the information. It has helped me understand something I was struggling to find an answer to.

Comments are closed.