180 & 100 NOTIFY in REFER Call Transfers

When you configure your Oracle Communications Session Border Controller to support REFER call transfers, you can enable it to send a NOTIFY message after it has sent either a 202 Accepted or sent a 180 Ringing message. If your network contains elements that comply with RFC 5589, and so expect the NOTIFY message after the 202 Accepted and each provisional 180 Ringing, you want to set the refer-notify-provisional to either initial or all, according to your needs.

Without this parameter changed from its default (none), the Oracle Communications Session Border Controller does not return send the NOTIFY until it receives the 200 OK response from the agent being called. If the time between the REFER and the NOTIFY exceeds time limits, this sequencing can cause the Oracle Communications Session Border Controller’s NOTIFY to go undetected by devices compliant with RFC 5589. Failures during the routing process can result.

You can see how a sample call flow works without setting the refer-notify-provisional parameter.

The 180 and 100 NOTIFY Not in REFER Call Transfers call flow is described above.

When you compare the call flow above to the one depicting the scenario when the Oracle Communications Session Border Controller has the refer-notify-provisional changed from its default, you can see that the Oracle Communications Session Border Controller now response with a NOTIFY in response to the 202 Accepted and it sends another after the 180 Ringing.This causes the event to be diverted successfully.

The 180 and 100 NOTIFY in REFER Call Transfers call flow is described above.

Sample Messages

In compliance with RFC 5589, the NOTIFY message with 100 Trying as the message body looks like the sample below. Note that the expires value in the subscription state header is populated with a value that equals 2* TIMER C, where the default value of TIMER C is 180000 milliseconds.

NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=360
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 100 Trying

Also in compliance with RFC 5589, the NOTIFY message with 180 Ringing as the message body looks like the sample below. Again, the expires value in the subscription state header is populated with a value that equals 2* TIMER C, where the default value of TIMER C is 180000 milliseconds.

NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=360
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 180 Ringing

Also in compliance with RFC 5589, the NOTIFY message with 200 OK as the message body looks like the sample below.

NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK

180 and 100 NOTIFY Configuration

You can apply the refer-notify-provisional setting to realms or to session agents. This section shows you how to apply the setting for a realm; the same steps and definitions apply to session agents.

If you do not want to insert NOTIFY messages into the exchanges that support REFER call transfers, you can leave the refer-notify-provisional set to none. This means that the Oracle Communications Session Border Controller will send only the final result NOTIFY message. Otherwise, you want to choose one of the two settings described in the instructions below.

To enable 100 and 180 NOTIFY messages in REFER call transfers:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type media-manager and press Enter to access the media-related configurations.
```
ORACLE(configure)# media-manager
```
Type realm-config and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#
```
refer-notify-provisional—Choose from one of the following settings, where the Oracle Communications Session Border Controller:
- initial—Sends an immediate 100 Trying NOTIFY, and the final result NOTIFY
- all—Sends an immediate 100 Trying NOTIFY, plus a notify for each non-100 provisional messages the Oracle Communications Session Border Controller receives; and the final result NOTIFY
```
ORACLE(realm-config)# refer-notify-provisional all
```
Save your work.