Teraquant 'No Fluff' Blog

SIP Subscribe/Notify provides extensions to the Session Initiation Protocol (SIP) “by which SIP nodes can request notification from remote nodes indicating that certain events have occurred” as introduced by the RFC. This mechanism can be used to enable traditional voice applications and enhanced features such as:

This functionality is typically deployed between an PBX/Application Server and an end-user such as an IP phone or soft client. It’s a bit like subscribing to a service to be notified when a specific feature event has triggered, such as “tell me when I have a voicemail waiting for me on the server”. When the event occurs, the endpoint will be notified with a SIP NOTIFY and the endpoint will indicate that by illuminating the Message Waiting Indicator (MWI) light on your endpoint/IP phone. A Busy Line Field (BLF) service will inform the subscriber when the colleague of interest is off the phone by changing the color on the endpoint BLF field.

This technical article will focus on how to troubleshoot SUBSCRIBE/NOTIFY.

Whilst configuring these features ON or OFF for your enterprise customers, endpoints and PBX/Feature Servers will refer to the feature name from the IP phone side, e.g., “To make this feature available on the phone, you must enable the option SPn Service – Network Provided Services: ACDAgent.” However the other party to the transaction, i.e. the feature server, being a different vendor will likely refer to this same feature using a different name. When troubleshooting interoperability between a new phone type or a new release or Feature Server software, it’s quicker and easier to go straight to analyzing the SIP protocol which speaks a standard common language, the language of SIP. Protocol analysis or SIP monitoring will be quicker, as long as the protocol analyzing tool makes things easy for you. More on that below.

Starting with a Bit of Theory

RFC 3265 describes the rules for the generation of SUBSCRIBE requests by the SIP client and responses by the Application/Feature server in NOTIFY message. SIP phones should generate and send SUBSCRIBE requests immediately to the Feature server after registering successfully.

The Feature Server generates a 401 challenge, similar to the 401 challenge for SIP registration message. The IP phone responds with the username/password previously set on phone, thereby authenticating the device on the server for subscription to this feature. The 200 response from the Feature Server indicates that the authentication credentials from this user were accepted for subscription to this service.

Subscription Expiry

Subsequent SUBSCRIBE requests are also sent by the end point when its subscription is close to the expiration time.

In the above, the Expires timer indicates the amount of time subscription will remain active. The endpoint will have to re-subscribe before the expiry time in order to continue monitoring the status of the features provisioned for that enterprise or set by them on their self-help portal. When the status of the feature changes for the monitored user, the feature server sends a notify with the updated status.

Characteristics of the NOTIFY Message

The immediate NOTIFY after the initial SUBSCRIBE message confirms the initial state of the features that the user has subscribed to, e.g., for user John, the administrator or John himself via the self-help portal could have subscribed to 4 of the 7 features available in package. The NOTIFY message after Initial SUBSCRIBE message (sent after Initial Registration) would give the status of the features John has enabled in the subscription.

The endpoint uses the subsequent received NOTIFY message from Feature Server to synchronize with the actual feature state on the Feature Server. The subsequent NOTIFY messages received by endpoint during the active subscription contains only the changed state instead of the status for all the features contained within the subscribed event package.

Troubleshooting SUBSCRIBE/NOTIFY Transactions

Feature or Service Packages are selectable at an enterprise customer level as supported by the PBX/Application server implementation. This article describes some of the most popular packages available on Feature Servers and indicates how they are analyzed using OCOM.

We will use the Oracle Operations Monitor/Enterprise Operations Monitor (OCOM/EOM) to demonstrate how to troubleshoot these CTI features. OCOM/EOM has been recently enhanced to simplify analysis and troubleshooting of these SIP SUBSCRIBE/NOTIFY transactions. Teraquant, being the original specialists for OCOM/EOM, continues to be the most accessible and expert source of training on how to get these problems isolated to root cause and flushed out of your network.

The Subscriptions page in release 5 of OCOM/EOM lists all Subscribe/Notify transactions (live and historic) seen and monitored on your network. Double clicking or filtering on any user or device allows you to drill down on message flows involving Subscribe or Notifies transactions and individual related Subscribe and Notify messages.

Troubleshooting the BroadSoft “as-feature-event” Package of Features

Below are examples of specific PBX features that are being activated on a collection of endpoints such as SNOM, Yealink/tiptel, Aastra, and Gigaset. BroadSoft presented “as-feature-event” as a way of specifying these features and offered them to ECMA International to be standardized so that IP phone manufacturers can implement those features. ECMA International is a vendor organization which exists to standardize PBX features control and optimize interoperability. Note: it also supports Busy Lamp Field but calls the group of features Smart BLF, not “as-feature-event” Group Package.

Subscription to “as-feature-event” Group Package.

In the sample message below, Endpoint is subscribing to the Feature Server for the SIP SUBSCRIBE as-feature-event.

If the subscription is successful, the Feature Server would then immediately reply back with a NOTIFY message with the status of all currently subscribed services within the “as-feature-event” package.

Reading the xml parts of the NOTIFY below, we can see that all four features:

1. doNotDisturbOn
2. forwardImmediate (Call Forwarding Always)
3. forwardBusy (Call Forward on Busy)
4. forwardNoAns (Call Forward on No answer)

are currently set to False on the Feature server for this subscribed user.

Changing a Feature Status

To change the feature settings a user/admin may navigate to the URL for managing the phone, login to the feature server or make the change from their Self-Help portal, if offered by the service provider. Upon change of any feature for the user with a valid subscription, a NOTIFY message is sent from the Feature Server to the Endpoint containing a full body of xml related to that feature. This can result in long NOTIFY messages sometimes even exceeding the maximum MTU and creating jumbo frames. So ensure your network can support these.

The Dialog Event Package

The Dialog Event Package is a group of features controlled by a Subscribe/Notify dialog, defined more recently by RFC 4235 which also monitors the state of calls. In other words, in addition to the SUBSCRIBE/NOTIFY messages, the system would also monitor SIP INVITES and BYE/200OK call control messages.

A common Use case is Busy Lamp Field where SUBSCRIBE/NOTIFY messages are used to monitor the phone status of a second party to know when they are off the phone.

The Busy Lamp Field (BLF) is a common example of how the DEP can be used to monitor the phone status of a second party. BLF is a feature commonly found in PBX systems that enables a user to see the call status of another extension on their phone. This is typically done by the switch monitoring the state of the second extension’s line, i.e. the SIP call control such as whether they are currently on a call or not. The BLF feature can be used to quickly identify when a colleague is available to take a call or when they are busy on another call.

The Call Sequence is as follows:

Conclusion

The most consistent way to troubleshoot and analyze these features is by using an intuitive tool that pairs the SUBSCRIBE/NOTIFY SIP protocol exchanges together, highlights the features being controlled and graphs the KPI’s of each transaction for all your customers and PBX/feature servers. The only tool to deliver this in a user-friendly way is Oracle Communications Monitor (OCOM) or EOM for Enterprise.

Teraquant initially launched OCOM/EOM (or Palladion as it was called then) in the USA & Canada in 2008. Contact us now for the most expert help from the guys who know OCOM/EOM best.