Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
BCM 450 R5 Find Me Follow Me problem on PRI
- Thread starter ljclives
- Start date
oldestgeek
Technical User
Do calls transferred manually to the same number work properly?
- Thread starter
- #3
OH yes - definitely. Slight correction on my post - calls transfer to cell phones but disconnect when call is answered. Definitely think it is either a problem with how I configured the FM/FM (dont think so) or it is a software issue. (if so does anyone know the specific patch that will fix?)
Speaking as an ex-long term local phone company employee you are awfully quick not to blame the carrier.
I have seen situations at the LEC where Trunk to Trunk transfers were restricted with COS. It sounds like that is what is happening.
Call comes in one one channel of PRI, Then you grab another channel to go back out. It is not until the second call is completed that PRI signalling tells the carrier switch this is a trunk to trunk.
It has been awhile so I cant remember if it was the 5E55 or the DMS we did that on.
Also on trunk to trunk transfers like this you can request the carrier drop one trunk once the new call is connected so as not to take up 2 trunks. This has caused me grief in the past.
Half the battle is getting someone at the LEC that knows what they are doing.
Post back when you find the solution. I would be curious to know what it ended up being.
Of course if you "ask" the LEC it is definitely not a problem on there side.
I have seen situations at the LEC where Trunk to Trunk transfers were restricted with COS. It sounds like that is what is happening.
Call comes in one one channel of PRI, Then you grab another channel to go back out. It is not until the second call is completed that PRI signalling tells the carrier switch this is a trunk to trunk.
It has been awhile so I cant remember if it was the 5E55 or the DMS we did that on.
Also on trunk to trunk transfers like this you can request the carrier drop one trunk once the new call is connected so as not to take up 2 trunks. This has caused me grief in the past.
Half the battle is getting someone at the LEC that knows what they are doing.
Post back when you find the solution. I would be curious to know what it ended up being.
Of course if you "ask" the LEC it is definitely not a problem on there side.
- Thread starter
- #6
Not necessarily. It has been to long since I messed with it so I am not going to explain this perfect.
Using PRI the carrier switch can know if you have forwarded or transferred and handle the call differently based on which you do, ie Two B Channel Transfer.
PRI calls carry a lot more information than just your typical routing information of a standard T1, hence the D-Channel.
I am not saying this is your problem. Who knows for sure until you resolve it.
I worked for Bell for almost a decade. If we were working with someone at the customer level that knew what they were doing then most of the time it was our fault. The challenge was getting a union employee to take on the responsibility and spend the time to get to the bottom of it. By the time it got escalated to me multiple techs had told the customer it was not a Bell issue.
I would make sure from someone at the switch level that they are not doing anything special in call handling. Then I would make them come out with a protocol analyzer and prove it to me – make some test calls, let me see it work. Make sure they are not dropping a B on the transfer on the protocol analyzer. I would rather be proven wrong by the LEC than to troubleshoot forever and not get anywhere.
These days in every case I am told by the LEC it is not their problem. I can only remember one time they proved me wrong.
Programming trunk to trunk on a Norstar or BCM is super simple and incredibly common. If there was a software issue everyone would be posting for this.
Using PRI the carrier switch can know if you have forwarded or transferred and handle the call differently based on which you do, ie Two B Channel Transfer.
PRI calls carry a lot more information than just your typical routing information of a standard T1, hence the D-Channel.
I am not saying this is your problem. Who knows for sure until you resolve it.
I worked for Bell for almost a decade. If we were working with someone at the customer level that knew what they were doing then most of the time it was our fault. The challenge was getting a union employee to take on the responsibility and spend the time to get to the bottom of it. By the time it got escalated to me multiple techs had told the customer it was not a Bell issue.
I would make sure from someone at the switch level that they are not doing anything special in call handling. Then I would make them come out with a protocol analyzer and prove it to me – make some test calls, let me see it work. Make sure they are not dropping a B on the transfer on the protocol analyzer. I would rather be proven wrong by the LEC than to troubleshoot forever and not get anywhere.
These days in every case I am told by the LEC it is not their problem. I can only remember one time they proved me wrong.
Programming trunk to trunk on a Norstar or BCM is super simple and incredibly common. If there was a software issue everyone would be posting for this.
Let me make sure I am not misunderstanding your question.
1. Call comes in on Channel x of PRI
2. Press Transfer on digital phone
3. Press 9 (or whatever destination code you are using)
4. System grabs channel y of PRI for outbound call
5. Dial telephone number
6. Called Party Answers
7. Hit Join.
8. Call is dropped.
btw..one channel or both?
1. Call comes in on Channel x of PRI
2. Press Transfer on digital phone
3. Press 9 (or whatever destination code you are using)
4. System grabs channel y of PRI for outbound call
5. Dial telephone number
6. Called Party Answers
7. Hit Join.
8. Call is dropped.
btw..one channel or both?
- Thread starter
- #9
Thanks dibthree. I definitely will pursue TELCO. Let me go over what is happening:
Issue is with the Find Me/Follow Me feature which is quite a bit more involved than a simple transfer. It is activated by licenses; I had some other issue with this BCM that were resolved with patches. The extenson I programmed for this feature is trying to have all his incoming calls 'find' his cell phone. When they ring his cell phone (after initially ringing his desk phone) the call is dropped as soon as it is answered. Tried with different cell phones and carriers - same result.
However on a simple call forward to the cell phone (which is a different feature than the Find Me/Follow Me) the call connects fine.
Issue is with the Find Me/Follow Me feature which is quite a bit more involved than a simple transfer. It is activated by licenses; I had some other issue with this BCM that were resolved with patches. The extenson I programmed for this feature is trying to have all his incoming calls 'find' his cell phone. When they ring his cell phone (after initially ringing his desk phone) the call is dropped as soon as it is answered. Tried with different cell phones and carriers - same result.
However on a simple call forward to the cell phone (which is a different feature than the Find Me/Follow Me) the call connects fine.
At this point I would suspect the configuration of the virtual DNs and/or the CallPilot. You didn't detail how they were set up so let's confirm them first. The VTs must have access to the PRI trunk group with the proper restrictions assigned and they must have at least 3 appearances of the DN assigned. Under Capabilities and Preferences, make sure that Handsfree is set to none and that everything else is unchecked except for Auto Hold.
You also have to go into the CallPilot and under System Properties, the maximum number of FM/FM sessions must be set to a number greater than 0, up to the system max defined under system resources in the BCM.
If that is all correct, are there any 47xxx type errors in the alarm log? There are quite a few that relate to the FM/FM feature than can direct you to where the problem might be.
The last thing I can think of is, are the original inbound calls coming into a call centre? If so, FM/FM won't work.
You also have to go into the CallPilot and under System Properties, the maximum number of FM/FM sessions must be set to a number greater than 0, up to the system max defined under system resources in the BCM.
If that is all correct, are there any 47xxx type errors in the alarm log? There are quite a few that relate to the FM/FM feature than can direct you to where the problem might be.
The last thing I can think of is, are the original inbound calls coming into a call centre? If so, FM/FM won't work.
- Status
Similar threads
- Locked
- Question
- Locked
- Question