SUBSCRIBE and NOTIFY methods

The SIP specification has been extended over time to support a general mechanism allowing for subscription to asynchronous events. Such events can include SIP proxy statistics changes, presence information, session changes and so on.

A user agent interested in event notification sends a SUBSCRIBE message to an SIP server. The SUBSCRIBE message establishes a dialog and is immediately followed by the server replying with 200 OK response. At this point the dialog is established. The server sends a NOTIFY request to the user every time the event to which the user subscribed changes. NOTIFY messages are sent within the dialog established by the SUBSCRIBE.

SUBSCRIBE are used to monitor remote extensions (both for presence and dialogs – calls information) and voicemails.

Similarly to REGISTER messages, subscribes have a specific time duration and must be refreshed by the UAC (User Agent Client) regularly.

Let’s see a typical voicemail subscription in action:

SUBSCRIBE sip:vmaccess*150@mypbx.wildixin.com:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.135.0.12:5060;branch=z9hG4bKtrxftxslfcy3aagf3c9s7
Max-Forwards: 70
From: <sip:150@10.135.0.1:5060>;tag=l0hih
To: <sip:vmaccess*150@10.135.0.1:5060;user=phone>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277
Call-ID: fi6am90efehg8ku2c1p2uwrvy@10.135.0.1
CSeq: 25646 SUBSCRIBE
Contact: <sip:150@10.135.0.12;line=16172>;+sip.instance="<urn:uuid:0d9a008d-0355-0024-0000-000276f3d796>"
Accept: application/simple-message-summary
Allow: INVITE, CANCEL, BYE, ACK, REGISTER, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO, PRACK, UPDATE
Allow-Events: dialog,message-summary
Event: message-summary
Expires: 240
Supported: replaces,100rel
User-Agent: Wildix W-AIR 03.55.00.24 9c7514340722 02:76:f3:d7:96
Content-Length: 0

SUBSCRIBE requests the voicemail status for extension 150. We have already seen most headers above. Please note that in this case a specific Event type includes “message-summary” which means voicemail info. The UAC also indicates that it also supports dialog events used to receive information about remote calls.

SIP/2.0 202 OK
Via: SIP/2.0/UDP 10.135.0.12:5060;branch=z9hG4bKtrxftxslfcy3aagf3c9s7;rport=5060
From: <sip:150@10.135.0.1:5060>;tag=l0hih
To: <sip:vmaccess*150@10.135.0.1:5060;user=phone>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277
Call-ID: fi6am90efehg8ku2c1p2uwrvy@10.135.0.1
CSeq: 25646 SUBSCRIBE
Expires: 240
Contact: <sip:vmaccess*150@mypbx.wildixin.com:5060;user=phone>
Server: Wildix GW-4.2.5.35963
Content-Length: 0

The UAS accepts the request and indicates to the client that the subscription will expire in 240 seconds.

NOTIFY sip:150@10.135.0.12;line=16172 SIP/2.0
Via: SIP/2.0/UDP 10.135.0.1;branch=z9hG4bK1308.a003bf56000000000000000000000000.0
To: <sip:150@10.135.0.1>;tag=l0hih
From: <sip:vmaccess*150@10.135.0.1>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277
CSeq: 1111 NOTIFY
Call-ID: fi6am90efehg8ku2c1p2uwrvy@10.135.0.1
Content-Length: 90
User-Agent: Wildix GW-4.2.5.35963
Max-Forwards: 70
Event: message-summary
Contact: <sip:vmaccess*150@mypbx.wildixin.com:5060;user=phone>
Subscription-State: active;expires=240
Content-Type: application/simple-message-summary

Messages-Waiting: yes
Message-Account: sip:vmaccess*150@wildix
Voice-Message: 1/0 (1/0)

 

The SUBSCRIBE is usually followed by a NOTIFY which reports the current status of the subscription. In this case the Server reports that there are messages waiting, the client will then proceed showing on its interface a message waiting information.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.135.0.1;branch=z9hG4bK1308.a003bf56000000000000000000000000.0
Max-Forwards: 70
From: <sip:vmaccess*150@10.135.0.1>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277
To: <sip:150@10.135.0.1>;tag=l0hih
Call-ID: fi6am90efehg8ku2c1p2uwrvy@10.135.0.1
CSeq: 1111 NOTIFY
Event: message-summary
Subscription-State: active;expires=240
User-Agent: Wildix W-AIR 03.55.00.24 9c7514340722
Content-Length: 0

The transaction is completed by the confirmation of receival of the message from the UAC.

NOTIFY messages as the one above will arrive at any time when the status changes.

Reason

An important Header we have checked above is “Reason”:

SIP reuses many standard replies and error codes used by web servers, which do not contain exhaustive telephony information.

To illustrate, a simple BYE does not indicate any problems which might have lead to the BYE such as an operator problem or ISDN error.

This gap is filled by the Reason header, which provides a more detailed information.

Here are some examples:

Reason: SIP ;cause=200 ;text="Call completed elsewhere"
Reason: Q.850 ;cause=16 ;text="Normal Call Clearing"

“Call completed elsewhere” indicates that the call has been picked up by another extension and thus the local device should not show the call as missed. This header will be added to a CANCEL message coming from the UAS that had been trying to reach the phone.

The second example – “Normal Call Clearing” – contains instead a Q.850 cause. This information is incredibly important as the cause of error can allow further debugging of disconnection problems with operators.

This header should be populated by T1 / E1 / ISDN Media Gateways and by SIP Operators whenever the call is terminated over PSTN.

Information request:



    I need more information on improving the business communications

    Privacy*: I have read and accept the Privacy*
    I want to receive exclusive content for System Integrators and MSPs on how to grow my Business

    Social Sharing

    Leave a Reply