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:firstname.lastname@example.org:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.135.0.12:5060;branch=z9hG4bKtrxftxslfcy3aagf3c9s7 Max-Forwards: 70 From: <sip:email@example.com:5060>;tag=l0hih To: <sip:firstname.lastname@example.org:5060;user=phone>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277 Call-ID: email@example.com CSeq: 25646 SUBSCRIBE Contact: <sip:firstname.lastname@example.org;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:email@example.com:5060>;tag=l0hih To: <sip:firstname.lastname@example.org:5060;user=phone>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277 Call-ID: email@example.com CSeq: 25646 SUBSCRIBE Expires: 240 Contact: <sip:firstname.lastname@example.org:5060;user=phone> Server: Wildix GW-22.214.171.124963 Content-Length: 0
The UAS accepts the request and indicates to the client that the subscription will expire in 240 seconds.
NOTIFY sip:email@example.com;line=16172 SIP/2.0 Via: SIP/2.0/UDP 10.135.0.1;branch=z9hG4bK1308.a003bf56000000000000000000000000.0 To: <sip:firstname.lastname@example.org>;tag=l0hih From: <sip:email@example.com>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277 CSeq: 1111 NOTIFY Call-ID: firstname.lastname@example.org Content-Length: 90 User-Agent: Wildix GW-126.96.36.199963 Max-Forwards: 70 Event: message-summary Contact: <sip:email@example.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:firstname.lastname@example.org>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6277 To: <sip:email@example.com>;tag=l0hih Call-ID: firstname.lastname@example.org 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.
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.