SIP: Understanding REFER Method
In our previous articles on Session Initiation Protocol (SIP), we have covered its basics, message flow, architecture, and an introduction to trace analysis by breaking down INVITE and REGISTER methods. Today let’s analyze a simple call transfer scenario using the REFER and NOTIFY method. We’ll explore the message flow and the key SIP headers involved in this process.
As part of its rich feature set, SIP provides several mechanisms to facilitate the initiation and manipulation of media sessions. Among them, the REFER method stands out for its ability to redirect a SIP request from one user agent (UA) to another, effectively changing the call’s direction. In this article, we’ll delve into the world of SIP REFER, exploring its working principles, use cases, and implications for developers and network administrators.
The REFER method indicates that the recipient should contact a third party using the contact information provided in the request.
- REFER must contain a Refer-To header — contact information about the 3rd party. This is a mandatory header for REFER.
- REFER can be sent inside or outside a dialog.
- A 202 Accepted will trigger a REFER request which indicates that other user agent has accepted the reference.
NOTIFY is used by user agents to get the occurrence of a particular event.
- Every NOTIFY will get 200 OK response if it is received by notifier.
- NOTIFY contain an Event header field indicating the event and a Subscription State header field indicating the current state of the subscription.
- A NOTIFY is always sent at the start and termination of a subscription.
Scenario: SIP Call Transfer using REFER and NOTIFY
Initial Call:
Let’s assume we have three User Agents: UA1, UA2, and UA3. UA1 is on an active session with UA2, and decides to transfer session to UA3.
Initiating the Transfer:
During the ongoing call between UA1 and UA2, UA1 decides to transfer the call to UA3. To initiate the transfer, UA1 sends a SIP REFER request. If UA2 can locate the user in Refer-to URI, it responds with a 202 Accepted response.
REFER Handling:
Upon receiving the REFER request, the UA2 processes the Refer-To header and locates UA3’s location and sends an INVITE with Replaces to the Refer-To URI.
NOTIFY Message:
Upon receiving response to the INVITE from UA3, a SIP NOTIFY message is sent to UA1, notifying it about the status of the REFER /transfer request.
SIP Fragments (sipfrag):
During the call transfer, media continuity is essential to maintain the audio or video stream between UA2 and UA3. SIP Fragments (sipfrag) allow UA2 and UA3 to handle media during the transfer process. These fragments help ensure that media remains uninterrupted while the transfer takes place. Status of the call to UA3 sent as sipfrag: 100 Trying/180 Ringing/200 OK. Once the call is established between UA2 and UA3 (***UA1 has received 200 OK in NOTIFY /sipfrag***), UA1 drops from the call.
Conclusion:
In conclusion, the SIP call transfer using the REFER and NOTIFY methods is a vital feature that enables users to seamlessly redirect ongoing calls to another user agent. During the call transfer process, UA1 initiates the transfer by sending a REFER request specifying UA3’s URI in the Refer-To header. Upon receiving the REFER request, UA2 ((or SIP proxy) processes the Refer-To header and locates UA3’s location, initiating a new call between UA2 and UA3 using an INVITE with Replaces. Meanwhile, UA1 is notified about the transfer progress through NOTIFY messages, ensuring transparency throughout the process. SIP Fragments (sipfrag) are used to maintain media continuity during the transfer, ensuring uninterrupted audio or video streams between UA2 and UA3. Once the call is established between UA2 and UA3, and UA1 has received the 200 OK in the NOTIFY/sipfrag, UA1 gracefully drops from the call.
