2-12
Cisco BTS 10200 Softswitch SIP Feature and Provisioning Guide, Release 5.0
OL-12397-13
Chapter2 SIP Subscribers
Diversion Indication for SIP Subscribers
Step 2 If not already done, add a default sip-timer-profile-id to the ca-config table:
add ca-config type=sip_timer_profile_id; datatype=string;
value=<sip_timer_profile_id>;
Diversion Indication for SIP Subscribers
Diversion indication provides supplemental redirection information to the SIP entity receiving a call.
The SIP entity uses this information to identify from whom the call was diverted, and why the call was
diverted. It also provides information for each redirection if multiple redirections occurred. This is
provided in the form of a SIP Diversion header.
Forwarding information allows applications such as SIP voice-mail servers to access the mailbox of the
original called party for proper outgoing greeting and message deposit when a forwarded call is received.
Billing systems also use the information to determine the charged party of the call where it is the last
forwarding party that is billed.
The BTS 10200 supports the Diversion Indication feature according to the specifications in the IETF
document draft-levy-sip-diversion-02.txt. For incoming calls, the BTS10200 uses the party number
information from the top-most and bottom-most diversion headers. The BTS10200 reads the diversion
count across all diversion headers to determine the total diversion count. For outgoing calls, The
BTS 10200 sends 0, 1 or 2 diversion headers, depending on the forwarding information of the call.
Diversion header parameter support is limited to the diversion counter and the diversion reason. These
two parameters in diversion headers are populated for outgoing calls and interpreted on incoming calls.
For INVITEs sent out by the BTS 10200, the following behavior applies:
•If no diversion information is available, no diversion headers are included.
•If there is an original called party, one diversion header is added to the outgoing INVITE message.
•If there is a last forwarding party, a second diversion header is added on top of the original called
party diversion header.
•Each outgoing diversion header is populated with the party number, the diversion reason, and the
diversion count.
•For Release 5.0, Maintenance Release 1 and later, privacy parameters are sent and received in the
Diversion header.
•For Release 5.0, Maintenance Release 1 and later, If the original called number (OCN) and/or the
redirected DN (RDN) are being sent in Diversion headers towards local SIP subscribers, and the
presentation value is not allowed, the system applies anonymous to them as follows:
–
If an OCN exists, it populates the URL as anonymous@anonymous.invalid in the To header.
–
If a Diversion header is added, it populates the user part of the diversion header with
anonymous.