Freaky forwarding problem

[macdouglas]

Customer has a BCM50 2.0,
This is what I know:
calls come in on an 800 number, are answered by AA, sent to CCR tree, node 0 is transfer to DN301

when the customer has his desktop set forwarded to his T-mobile cell and his cell is powered on, callers get a fast busy

when the customer has his desktop set forwarded to his T-mobile cell and his cell is powered off, callers get his cell phone voicemail

We have also tried forwarding to the AT&T phone of another employee, same thing happens.

Customer can call his cell from his desktop and it rings fine.

The weird thing is that I can call the main number of the office, enter his DN and it will forward to his cell whether it is on or off.

What difference does the state of his cell phone have on the way calls are forwarded?




"Never hold discussions with the monkey when the organ grinder is in the room."
-Winston Churchill

 

[SupportDude]

What type of trunks are you using?

-SD-

http://www.mysupportguy.net

 

[macdouglas]

PRI, No voip



"Never hold discussions with the monkey when the organ grinder is in the room."
-Winston Churchill

 

[SupportDude]

I've seen this cause some strange problems with ECF.

Go to Resources>Telephony Resources and highlight your PRI.
In the bottom panel select the Trunk Module Parameters tab.
Make sure the "Send Name Display" box is not checked.

-SD-

http://www.mysupportguy.net

 

[macdouglas]

No dice, condition persists. The big problem is that I'm not on site but I was there yesterday and I'm trying to avoid a return trip. I just don't think I can walk the user through BCM monitor and be confident that he'll be able to tell me what he sees when this happens.



"Never hold discussions with the monkey when the organ grinder is in the room."
-Winston Churchill

 

[SupportDude]

Very strange, especially the cell phone off or on part.
Perhaps its something in the setup message that T-mobile doesn't like, or is missing.

Are all the latest patches installed?

-SD-

http://www.mysupportguy.net

 

[macdouglas]

It's about a year behind but....

New wrinkle, I had the cust open Monitor and look at lines,

when his cell phone was on and I called in, all he saw was a too-quick-to-read blip on the line and then it goes back to Idle

when his phone is off, it shows the incoming call connected and it doesn't go idle until it connects to his cell VM.

How does it know that his phone is ON!?



"Never hold discussions with the monkey when the organ grinder is in the room."
-Winston Churchill

 

[SupportDude]

Have the customer use the UIP tab instead of Line Monitor.
You can select the PRI bus and actually see the D channel messaging. This might provide a clue in the setup or disconnect information elements. The BCM

The phone off/on thing would come from T-Mobile.
The voicemail system resides at one of their offices.
I assume when the cell phone is powered on it registers in their network as available, so calls are forwarded to the cell site where the phone currently resides. When the phone is off it goes directly to the voicemail at their office.
It seems the problem is in the transition from land line to wireless. I think you're on land lines all the way to the cell tower serving the area where the cell phone resides.

-SD-

http://www.mysupportguy.net

 

[macdouglas]

What I can't figure out is how the system knows,

the time it takes for the line to show that the call is being dropped seems like it isn't enough to even get a response from the mobile network.

also, it happens when forwarded to an iPhone on AT&T which also goes to mobile VM when the phone is off.

So is it a LEC issue, a Wireless network issue or a system issue?



"Never hold discussions with the monkey when the organ grinder is in the room."
-Winston Churchill

 

[macdouglas]

And furthermore...

when I call into the main office number which is on the same circuit as the 800 numbers and dial 301, it forwards to his cell whether it's on or off.

so that would seem to indicate that the ccr tree that sends the call is responsible but again:

they come in and go out on the same circuit so why does it only SOMETIMES matter that his cell is on



"Never hold discussions with the monkey when the organ grinder is in the room."
-Winston Churchill

 

[telcodog]

This is going to be tough to get resolved. It looks like you have a few different carriers involved here and it all appears to reside in the digital world.

Given the fact that when you call the local number that the 800 service is terminated on, everything works fine, I would start by having the call bypass the voicemail to eliminate it as being the culprit. For a test, pick another target line and assign the users DN to it so the call will ring his set directly, then try the call with the cell phone on and off. If the same thing happens, you know voicemal is not causing this.

If it continues, I would suspect the SS7 signaling network. While viewing the UIP information in the monitor, I suspect that all you will see is disconnect normal on the D channel. This of course means that somewhere between all these carriers, one of them is sending a disconnect message to your PRI and the BCM is responding correctly. I say this because of your comment about the monitor message being so fast you can't even read it. That is exactly what will happen using SS7 signalling. It's job is to find and reserve a path through the network for your call and is way faster than any PRI. If it can't find one or receives something unexpected, the call will be denied and your PRI will receive the disconnect message. Hence the rapid message. It's very very fast stuff. Add to this the fact that you are probably running through several network switches from different manufacturers and you can see the possible problems.

If that's what the problem is, you will really need to schmooze someone on your carrier side to monitor the network portion to see where that disconnect is coming from. With the info from your post, I suspect your PRI provider is the culprit but you're going to have an uphill battle convincing them that they are causing the problem. They'll tell you they are just responding to a message from the far end (not the BCM, but the cell phone providers).

You're gonna need a lot of patience on this one.

 

[telcodog]

If you're not very familiar with SS7 and it's impact on 8XX and mobile services. you can start by looking here.

http://www.mobilein.com/ss7.htm