What are the benefits and challenges of using SIP Diversion header for call redirection?

Diversion header indicates a deflection of the destination of a call. Ex. User A calls User B, but User B has deflected/forwarded his incoming calls to User C. User C receives the call getting Diversion header knowing who did the deflection. Diversion header contains few parameters as: - "counter": indicates how many deflections have been done (each deflecting entity should add a new header on top of others with incremented counter value). It can be used as a fail-safe mechanism against infinite deflections to avoid routing storms/loops within VoIP networks; similar to how Max-Forwards header is used. - "limit": controls max count allowed - "reason": obviously indicates the reason Similar to History-Info. Diversion is defined in RFC 5806

Diversion header supports three parameters: counter: This contains the total number of diversions that have occurred. screened: This indicates if the diversion number is user provided (“no”) or network provided (“yes”). privacy: Certain conditions require that the diversion information be encrypted. This parameter shows how privacy has been applied.

The SIP Diversion header is a component of SIP messaging used to indicate that a call has been redirected from its original destination. When a caller dials a number that is forwarded to a different number, the SIP Diversion header can be included in the SIP message to show the original number dialed and explain why the call was redirected. Additionally, this header can carry more detailed information, such as the identity of the party that redirected the call, their privacy preferences, and a record of the redirection history. This functionality is crucial for maintaining the transparency and traceability of call flows in SIP-based communication systems.

Any change in RURI host or userinfo part will be considered as redirection or diversion. DIVERSION header is included by the Proxy/UAS who is aware of the redirector/forwarder config. Its not a standard header, but widely used. The standard headers but have less acceptance is HISTORY INFO header.

The SIP Diversion header enhances SIP Trunking by improving call routing and billing accuracy, ensuring calls are correctly directed and billed based on the original number. It also boosts caller experience by providing details about call redirection, allowing callers to make informed decisions. Additionally, it enables advanced telephony features such as call recording, screening, and analytics, making it a versatile tool for managing complex communication networks and enhancing service customization.

1- Provides ability to pass on the Originator or Original Caller-Identity. 2- Used by cariers to bill the B-party/Redirector/forwarder. 3- Used for Call authorization where From or Original Caller is not the Carrier provided number. 4- Used for porting scenario where middle number concept is used. 5- Diverison has extension parmaters which allow us to understand the history of redirection and reason for redirection as well.

The SIP Diversion header, while beneficial, introduces challenges such as compatibility issues, as not all devices support or interpret it consistently, leading to potential errors. Privacy concerns are also significant, as the header can disclose sensitive call information, necessitating strong security measures like encryption. It increases system complexity and overhead, impacting performance and requiring more maintenance, making its management more demanding.

1-Diversions are widely used and if the exact extensions are not used, that will create more confuion and errors. 2- Most SBCs can handle Diverison header and HIstory-Info interop. So the compatibility issues are lessened. 3- If multiple DIVERISON header are introduced along the way and not screened properly before Egressing out to customers, this will expose internal routing. 4- Multiple Diverison is more error prone to Billing systems if not carefully setup. 6- Most Carriers do not consider DIVERISON header for Call screening. So customer expectation in not met.

1- DIVERSION header can be effectively use in conjuction with other optional parameters. REASON PRIVACY COUNTER SCREEN 2- Without above parameters we can only have partial information which will led to more complex troubleshooting.

I wanted to point our that diversion headers when using SIP circuits may also impact the way 911 Emergency calls are routed within Telco Systems.

As part of adding a Diversion header, it may generate a second STIR/SHAKEN token which may cause the forwarded leg of the call to be rejected if the next switch is unable to handle 2 tokens.

As a general rule of thumb the owner of the forward should now be the owner of the token and take responsibility for the success of the forward. how can the original caller attest to the new Destination's reliability without knowing the relationship and reason for the forward and who they are handing the call to? But we have carriers who are changing the To header to match the original to in the diversion. not taking into account the far end will reject for invalid identity on the token because they didn't send a new token.

Adding a Diversion header might generate a second STIR/SHAKEN token. This can cause issues if the next switch in the call path cannot handle two tokens, potentially leading to the rejection of the forwarded leg of the call. It can also impact the routing of emergency 911 calls within telecommunications systems. Moreover, there's a responsibility shift when a call is forwarded. The entity initiating the forward should ideally assume responsibility for the call’s success and the authenticity of the new destination. Problems can arise, for example, if carriers alter the 'To' header to match the original 'To' in the diversion without issuing a new token, leading to rejections at the far end due to invalid token identity.