CS 1000 with PRI NI2 and Redirecting Number Issue 2

[jcoomans]

OK, I just ran into this issue, and I am looking for insight into how widespread it might be. . .

We often deliver SIP Trunking to customers using an Adtran Total Access 908e. This converts SIP to a standard NI2 PRI handoff that even the oldest M1/CS 1000 can handle without needing an upgrade. However, sometimes when we deliver a call to the Adtran for conversion, it contains a DIVERSION header, because the call was forwarded. When this header is in the SIP invite, then the Adtran is mapping that to the Redirecting Number field in the call setup on the PRI D-channel.

The end result is that when we sent a redirecting number to the public PRI interface on the CS1000, and that call was then forwarded to voicemail, it would not go to the proper voicemail box. The CS1000 was using the Diversion Header phone number that we sent INSTEAD of the extension.

Is this common in Meridian 1s and CS 1Ks? Why, in the world, would the PBX use the Redirecting Number it received on a public PRI interface as the redirecting number when the call rang an extension and was then forwarded to voice mail? Why would it not simply either ignore what it received on a public interface, or replace it with the extension's redirecting number when forwarded.

 

[KCFLHRC]

The PBX is going to look for what ever digits are sent down the D-Channel and route the call accordingly. Not a PBX issue

 

[Wanebo]

I believe you answered your own question when you stated that "This converts SIP to a standard NI2 PRI handoff". NI2 just simply doesn't contain all the information that a SIP header can contain and most appliances that do such a conversion strip and massage the SIP information into a PRI standard that just mostly matches the received signaling. The PBX can't substitute information it never sees or that it sees in the wrong part of the modified signaling.

 

[StanleySteamer]

If the originally dialed number is known then the CallPilot voicemail will send the call to the mailbox for that number, even if it is external. "Design intent" as they say.
Sometimes the workaround is to add that number as an extension DN in the preferred mailbox. Or you could add it to the SDN table. That way you can give a short announcement then transfer to another extension.

 

[jcoomans]

Well, thanks for the info. . .looks like this is going to be a common issue. We've solved for it in the Adtran by stripping this off the SIP header, but again, it seems crazy to me that it would pass this along from a public interface. I understand if this is a private networking inferface (MCDN) where this would be needed, but not on a public one.

Thanks for the input. . .looks like we'll need to strip this often.

 

[bignose21]

don't know if this is available to you or would help in the RDB

ARDN Allow last redirecting Number, where: basic-4.5
(NO) (NO) = treatment for originally called
number.
YES YES = treatment for last redirecting
number.
RPO RPO = treatment for last redirecting number
if OCN is Public


Note:
If ARDN= RPO, and the call lands on a
voice mail system, the voice mail would
be left against the last redirecting party's
mailbox.