Siemens 8K/OSV no "Mobile may be switched off message"

[TDMman]

When calling a mobile that is switched off (with no voicemail) from a Siemens 8K/OSV system you do not get the message "This mobile may be switched off, please try later or send a text" you get NU. We have several different carriers all with the same result NU, we also have a Siemens ISDX network and they all provide the correct audio message without any problem, it seems only to be a problem on the Siemens 8K/OSV system.
There is a call progress description message, the carriers send back a code 2 "Destination address is non-ISDN" unfortunately the 8k/OSV system does not open the audio path on a code 2, only a code 8!
If you plug the E1 trunk into a Trend tester and make the call you get the correct audio message, does anybody know why the 8k/OSV blocks the audio message? our system is in the UK

 

[Iamnothere]

The 8K does not directly handle E1 trunks, but rather it uses gateways to connect to the PSTN. SIP Signaling happens between the OSV and the gateway, then the gateway converts SIP to E1/T1; therefore it would be my guess that the gateway has a slight misconfiguration.
Which gateway are you using: Mediatrix 363x? RG870x? RG830x? ......etc

 

[TDMman]

Thank you very much for a quick responce, yes as you say the 8K connects to the E1 trunks via Gateways, we are using RG8702's and the trunks are ISDN30e we are using BT and C&W, both are exibiting the same problem.

 

[Iamnothere]

I'm in the USA, so perhaps someone more familiar with the RG8702 and E1 trunks can join in. That message regarding ".. the mobile may be switched off..." is coming from the PSTN, not the OSV's media server, correct? After receiving the response from the PSTN, the RG is sending a corresponding SiP message to OSV determining the response to the calling party. In the OSV, is your RG8702 endpoint configured as native SIP ("SIP Trunking" is the OSV entry) or "SIPQ"? I believe it works either way. My suggestion is to consider changing that SIP signaling method between the RG and OSV, and see if that resolves the problem. There are many OSV installations in the UK. I will check with a UK buddy and see if he has seen this before. Stay tuned.

 

[TDMman]

The message "This mobile may be switched off, please try later or send a text" is being sent by the carrier, but the 8K/RG8702 does not open the audio channel so the caller does not hear the message, the endpoints are configured as "SIP Trunking". Thanks

 

[Iamnothere]

Please contact the tech who previously visited your site regarding this matter. He can bring you up to date on this trouble. Cheers.

 

[TDMman]

We have had a response from Siemens that the system is working as designed!! Why would you design a system not to receive helpful messages from the carrier, does the PSTN network in the UK differ from the US in this respect, is OSV/8K not fully compatible for the UK market?
Does anybody have a OSV/8K system in the UK connected to BT’s ISDN30e that receives the “Mobile may be switched off message? I would be interested to know.

Thanks

 

[Iamnothere]

It is my understanding that the problem is not OSV, but rather the RG87xx. In this specific scenario, your PSTN vendor sends "PI=2" which tells your gateway to disconnect, so OSV disconnects. This problem is not just a Siemens problem. With all the different combinations of gateways, trunking variations, and PSTN vendors, it is probably not possible for ANY single gateway to be able to handle every scenario in every country, as telecomm technology is changing rapidly.
Your RG8700 is (hopefully) set to the country code "UK", where the progress indicator (PI) values you have mentioned are apparently hard-coded. The RG is expecting an "8" but your vendor sends a "2".
To prove to you that this is a telecomm-wide problem and not just a "TDMman" problem, see this US patent document for Cisco:

http://www.freepatentsonline.com/7529233.pdf

It describes your EXACT scenario. Did it resolve their particular problem? I do not know!

If Siemens says that the RG is working as designed, then that is a valid response, as the RG was no doubt designed to accommodate the typical UK PSTN PI response, which is apparently "8". Your posts indicate that unfortunately 2 UK PSTN vendors have strayed from the UK norm, and they use a different value, "2", which instructs the RG8700 to disconnect. The RG is doing what is was designed to do: follow the "PI" instructions from the PSTN vendor!

Have you attempted to speak to your telecomm vendor? Perhaps the vendor can revise that specific PI within your circuit(s). If not, the they, too, will probably indicate that their ISDN is "working as designed"! Perhaps you could request a site-specific patch for the RG8700, or perhaps even a OSV patch. For example, if the RG receives a PI=2, and sends a corresponding SIP signaling command to OSV, a parameter in OSV could be manually configured to determine whether "PI=2" means "disconnect" or "open audio path" per ENDPOINT (RG8700). Have you considered using a different PSTN vendor which DOES use PI=8 for this scenario? Perhaps you could try a different gateway, such as the HiPath 4000 RG8300. Do you have a HiPath 4000 AP3700-9 IP shelf with AP-E stuffed into storage? It can be transformed into a RG8300 gateway!!! There's also the third-party Mediatrix gateway, which handles E1 and converts to native SIP (what you need), but I do NOT KNOW if it properly handles your PI=2 versus PI=8 problem. You would need to consult with Mediatrix before spending money. Their website is:

http://www.media5corp.com

Did you purchase this telecomm system from Siemens? Perhaps they are willing to participate in an experimental exchange of RG87xx and Mediatrix.

In summary: your problem is not "specific" to Siemens, but rather is an ISDN<>SIP problem. Cisco has definitely experienced the problem as detailed in the patent application. With rapidly changing telecomm technology, these inconsistencies are going to happen - but unfortunately this one has negatively impacted YOU. You have options. Think positive, and please re-post WHEN you get the issue resolved.