[VoiceOps] Diversion header with counter=99

[Matthew Yaklin]

Here is a chunk of the INVITE.

Max-Forwards: 21
Diversion: <sip:+1585xxxxxxx at 10.x.x.40:5060>;reason=unknown;counter=99   <---------------------
Diversion: <sip:+1585xxxxxxx at 10.x.x.40:5060>;reason=unknown              <---------------------
X-DCL-UCP-DNIS: 585xxxxxxx

We are not doing any of this purposely. This is the default behavior of a Metaswitch customer who is using the EAS's incoming call manager options via what they call the "commportal".

They can put a forward/rule on their number that says forward to a TN, wait 30 seconds (less or more seconds), and then send to their number's voicemail. This is not the usual find me/follow me that we can add in what Metaswitch calls the CFS.

Back in the day we used to use find me/follow me like everyone else. I recall having to always set the amount of time to ring a cell phone short because we did not want the call to go to the cell phone's voicemail. I am thinking my asterisk days.

I am guessing Meta adds counter=99 to tell the called party not to forward it to voicemail even if you try to ring the cell phone for 60 or longer seconds.

ATT (mobility) seems to be the only telephone company we know of that chokes on it for a specific user we have that is dealing with the issue. We have tested other situations and it just works including Verizon for example.

At first Intelliquent said remove the top diversion header but having multiple diversion headers in an INVITE is ok so it must be the counter causing the issue when delivering the call to ATT. In my opinion.

Just odd Metaswitch would do this by default if they knew it would cause issues. At the very least they knew Level3 had troubles with it back in the day.

Matt




From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Joseph Jackson
Sent: Wednesday, February 3, 2021 5:14 PM
To: Matthew Yaklin <myaklin at firstlight.net>; voiceops at voiceops.org
Subject: Re: [VoiceOps] Diversion header with counter=99

Hi Matt,

>From rfc5806

   The Redirection Counter value minus 1 SHOULD be stored in the
   diversion- counter associated with the top-most Diversion header.
   Presence of the diversion-counter for the bottom-most Diversion
   header is optional.  If present, the diversion-counter of the bottom-
   most Diversion header SHOULD be 1.


If it's the bottom diversion header then anything not with 1 is going to have problems.

Why are you setting the counter to 99?

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Matthew Yaklin
Sent: Wednesday, February 03, 2021 3:01 PM
To: voiceops at voiceops.org<mailto:voiceops at voiceops.org>
Subject: [VoiceOps] Diversion header with counter=99

All,

Has anyone ran into an issue where the diversion parameter "counter" is causing some calls to fail to an error message?

Diversion: <sip:+1585xxxxxxx at 10.x.x.40:5060>;reason=unknown;counter=99

Basically we have a customer who forwards a call to their ATT cell. ATT plays an error message yet the customer's setup will pull the call back to our switch's voicemail after 30 seconds. This actually works if you let the error message play long enough. This setup works everywhere else like Verizon for example with no error message played. It rings as expected.

Our invite goes out with two diversion headers and the top one simply duplicates the bottom but with the counter param added.

I guess Level3 used to have this issue as well in the past? Because I found a Meta doc talking about this exact problem.

Any advice is welcome. Thanks,

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20210204/2afe1da3/attachment-0001.htm>