Block Offnet to Offnet transfer

Unanswered Question
Apr 13th, 2007

Callmanager 5.1.1a.

Offnet to Offnet calls are blocked using the service paramter "Block Offnet to Offnet transfer" so that transfers cannot be done from an ip phone, if the source and destination are pstn numbers. This works just fine. The phone do see a message on the LCD display "External Transfer Restricted" when they try to perform a transfer. All my gateways and route patterns have a Call classification of Offnet.

We are having an issue with pstn user calling an ip phone and the ip phone transfer the call to voicemailbox of a user. A CTI Routepoint *[1-8]XXX is setup which is call-forwarded to voicemail. This CTI route point is used to direct transfer to voicemail.

Here are the two scenarios that we have tested so far.

Case a: Internal call: Ip phone user a calls ip phone user b and tells her to transfer call to user'c (2781) voicemail, ip phone user b hits transfer softkey, dial * 2781 + transfer soft key and the transfer completes fine.

Case b: External call: Pstn user calls from cell phone to user b and tells her to transfer to user c's (2781) voicemail, ip phone user b hits transfer softkey, dial *2781 and when you hit transfer soft key, you get the message "External transfer restricted"

Why would Callmanager treat a call transfer to a CTI Route point (*[1-8]XXX) as an offnet call and block the transfer ? Note that CTI route points dont have an explicit call classification. So i would believe it should consider it as Onnet and not Offnet.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gogasca Mon, 04/16/2007 - 12:59

Hi Sankar

Will repdroduce it in our lab during this week and give u an update.

thisisshanky Tue, 04/24/2007 - 17:54

This problem has been fixed with TAC's help.

New bug with 5.x.

CSCsi60732: Onnet Call Transfer to hunt pilot marked as Offnet

With CM 5.x, Hunt pilots are marked as Offnet instead of Onnet. Voicemail is setup using hunt pilots. So when a call was being transferred to *XXXX, the CTI Route point would eventually forward that to voicemail hunt pilot and according the Callmanager, this call is an offnet call.

With help from TAC we identified the following traces where the transfer was being blocked.

04/19/2007 17:18:01.888 CCM|Transferring - Cannot Complete Transfer with

PrimaryTransferredIsOffnetDevice =1,

SecondaryTransferDestinationIsOffnetDevice

The fix for this is not yet available other than keying in some database commands to mark a call to each hunt pilot in Callmanager as Onnet. This can be done using the following set of commands.

a. Login to the Publisher via ssh (You can run these queries from direct CLI access as well).

b. Run the following CLI command:

i. To update a single Hunt Pilot:

run sql select pkid, dnorpattern, fkroutepartition from numplan where dnorpattern = ''

And then run the following query:

run sql update numplan set tknetworklocation='0' where pkid=''

ii. To update for all Hunt Pilots, then

run the following query:

run sql update numplan set tknetworklocation='0' where tkpatternusage='7'

Note that the tkNetworkLocation represents the value for Call Classification stored in CM database

. value of 0 would mean OnNet

. value of 1 would mean offnet

. value of 2 would mean Use System default which would take the service parameter value.

c. To verify the changes made by this command, run the following CLI command:

run sql select pkid, dnorpattern, tknetworklocation from numplan where dnorpattern = ''

d. The output for update queries would be usually like below:

admin:run sql update numplan set tknetworklocation='0' where pkid='4fcdd0d5-9f51-0b2d-3f90-23bb670f4336'

Rows: 1

The above fix is not permanent. It will be officially available in an ES that will come out in the near future. Until then if you use the above set of commands to fix the CM database, any upgrade to a new service release of Callmanager may overwrite the changes made via these commands.

Hope this helps someone!!

Sankar.

wboonshen Fri, 09/21/2007 - 23:47

I'm having this problem now and have upgraded the CM to 5.1.2b but the problem is still occuring. I've tried keying in the sql update command but couldn't because it says that 'No update permission'.

Any ideas how i can proceed?

wboonshen Sat, 09/22/2007 - 01:44

Dear all,

Problem is solved after unchecking the MTP box at the gateway configuration. why did this caused the call features like hold, transfer and conference to fail?

SaM

Actions

This Discussion