Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Cisco Call Manager with Cisco expert Dave Goodwin. Dave is a Diagnostic Engineer within Ciscos Customer Advocacy business function. Feel free to post any questions relating to Cisco Call Manager.
Dave may not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through June 29. Visit this forum often to view responses to your questions and the questions of other community members.
When configuring directories on Soft Phones I can specify a search base for the LDAP directory. This allows me to partition a directory so a Soft Phone user sees only a portion of the directory.
Is there any way to specify the LDAP search base on IP phones so groups of phones see different subsets of the whole directory?
Yes, you can do this, and there are a few different ways to do it, not the least of which is to write your own LDAP search web script which returns the proper XML objects to the IP phones. This can be done using the web server of your choice (assuming it can return the header "text/xml") and whatever scripting language you like that can interface to an LDAP server -- Perl, PHP, etc.
One solution which Cisco offers to accomplish this task is the Cisco IP Phone Services SDK. You can get this by going to the URL:
One of the documents available online under that link is the LDAP Search COM Server programming guide. This COM server is included in the SDK for use on your IIS web server and as you will find in the documentation is able to use a different search base on the LDAP server to generate the directory listing.
Once you have tweaked the script to your liking, you would need to go into System -> Enterprise Parameters and modify the Directories URL to the correct location.
Using the T1 voice blade for the 6000 we get a couple of seconds of echo on certain calls. I know this is the expected behavior on this card as I have Cisco documentation stating this. When using a 3640 as a gateway I do not experience the echo. My question, is Cisco going to try and correct this?
Is the echo you hear when using the 6608 blade only the first couple seconds of the call? Or is it a couple seconds of echo somewhere in the middle of the call?
Also, when you use the 3640 instead, are you using it with the same PRI circuit(s) as with the 6608 blade?
Have you tuned the dB settings in either direction on either the CallManager (for the 6608 blade) or on the 3640 voice port?
Hi Dave, I did get some information from an EBC visit that there will be a new load for the 6608 module in the near future that addresses the convergence time for the echo cancellation. I searched the Bug navigator, but didn't find a hit. Have you heard anything about this?
I don't think you'll find a bug ID for this, because it's actually a large-ish project undertaking to address this issue, rather than a simple defect that can just be resolved.
Email me offline and I can give you more info if needed.
We hear echo for the first couple of seconds of the call. The 3640 was used for testing on the same PRI as the 6608. We did tune the dB setting but I think we are getting to the point where changing the setting much more would affect other things. Not all calls hear the echo just a few but they are frequently used phone numbers.
What were the settings on the 3640 for input gain and output attenuation?
What settings were tried for the 6608 audio adjustment in the gateway config screen? After each change, did you reset the gateway?
We are using H.323 endpoints that support initiating call-transfer (both H.450.2 and Cisco transfer). How do you configure the Call-Manager to accept transfer requests from the end-point device. Note that the 5300 and the Cisco IP-phone will be the transferred and transferred-to end-points. Thanks..Andy
Right now, Cisco CallManager does not implement any of the H.450.x Supplementary Services, including H.450.2 Call Transfer. This issue is currently being discussed in marketing and development to determine the what, the how, the when, etc. so I don't have a firm answer for you at this time for when this may be available. I have sent a note to one of the "people in charge" that may be able to provide more info about this, and I will post it when I find out.
I'm not sure what you mean by "Cisco transfer." Can you further explain that?
So just to make sure I understand, the call will come in the 5300 which will call your H.323 endpoint which terminates the call. It will do whatever call processing it wants to do, and then wants to transfer the call from the 5300 to an IP phone? (e.g. 7960)
The only ways I know of that you could do this currently is if your endpoint implements a Skinny Station stack (just like an IP phone), or uses a CTI language to communicate with CallManager, such as TAPI or JTAPI. CallManager can handle transfers using those methods, but not H.323 (yet).
If this isn't acceptable or you need more info, maybe you could elaborate on exactly what your H.323 endpoints are and what task(s) they will accomplish. Are they actual H.323 user terminals and the users will be doing the transferring? Or are they part of an automated system such as an IVR which processes data and then transfers to another number based on some results? Anything more you could explain about this will help, as there may be other options available to you.
Dave, thanks for the reply.
Let me be more specific about "Cisco transfer". In addition to the H.450.2 transfer supported in the Cisco gateways the documentation also describes a Cisco method of transfer (H.323 Call Redirection Enhancements using the facility message with "facilityReason of callForwarded").
Regarding the H.323 end-point, it is an IP-IVR application with AutoAttendant capabilities and capable of generating either H.323 transfer message. For the configuration we are deploying we would like to know if the transfer message would pass transparently through the Call Manager, thus allowing the originating 5300 gateway to be transferred. So, in summary, the PSTN call terminates at the 5300 and is routed to the IP-IVR for handling. If needed, the call is then transferred to either a 7960 or outbound through the 5300.
If these scenarios are not possible how would I be able to obtain implementation information on interfacing to the CallManager via TAPI, JTAPI? That would be very helpful if all else fails.
Thanks again, Andy
I had successfully programmed IVR applications using CCM's TAPI driver. It includes Transfer, Conference, etc.
I don't know too much about H450.2 protocol and services, but here is what I know and I hope is useful for you.
Any kind of transfer, or conference function called using TAPI, will simply cause the audio streams to be redirected from one to another.
In case of transfer, it is redirected to the resulting gateway. In case of conference, it is redirected to conference bridge.
Hope this helps.
There are a couple of restrictions mentioned in the document you reference, which is located at:
One of them is that you must use IVR processing on the router. That being said, I interpret that to mean that if you will also be performing IVR functions on your box, then we have gone from 2 stage dialing to 3 stage dialing. Probably not what you want to do.
Another is that an H.323 Gatekeeper must be used. In a carrier network, I don't presume that to be a problem, but just thought I'd mention it.
Now, one thing I have found through further reading is that IOS gateways (including the 5300) do partially support H.450.2 Call Transfer -- not the Cisco transfer as you are referring to it -- according to the doc at:
And the way I read it, if the call comes in through the 5300, the IVR on the MMind box terminates it, and initiates an H.450.2 Call Transfer to an IP phone off the CallManager, then the MMind is the transferring party (fine), the 5300 is the transferred party (according to the above doc, this is fine) and the CallManager is the transferred-to party... also note that only blind or non-consultative H.450.2 transfer on the 5300 would work.
Now, here is where I am a little short on how things work. When an H.450.2 call is being performed and the transferred-to party is being called, is there anything that distinguished that transferred-to call and a normal new call? My guess is yes, but I could believe it either way. In any case, I think this is the part when things may break down with this idea. Send comments if you have any.
Now, on to the final issue...
Since I have found out that currently H.450 is not anticipated for CallManager within the next year, you should look into using a TAPI or JTAPI client to handle the CallManager interface. CallManager has TAPI and JTAPI service provider interfaces which support network-based transfers, hold, and other supplementary services. For 3rd parties developing AA and/or IVR systems that are IP based, the TAPI or JTAPI approach are recommended.
TAPI information can be found at:
JTAPI information can be found at:
Also, aliao may be able to provide additional information and experiences, he has been posting on this thread as well. Good luck!
Just to close the loop. We were able to finally resolve the call transfer by 'homing' the originating calls to the MMind AA first and then transferring the calls onto the CallManager using H.450 commands back to the gateway. We will be interested to see when either SIP or H.450 supplementary services are supported in the CallManager in the future.
Thanks for your help and information.
Excellent news. So just to make sure I understand... you were able to successfully complete H.450.2 transfers in this scenario where:
MMind AA - transferring party
IOS gateway - transferred party
CallManager - transferred-to party
Is that correct?
Re: Call transfer with CCM and/or Gateway
I have a TAC case pertaining to this effort: we are trying a 1st step... getting a Cisco 3640 gateway to try a transfer... could you shed any lite or heat on Case B550988.
Richard, I read the case notes and I need a little more information on what kind of 3rd party Auto Attendant you are using, and what devices it is talking to.
If it is talking only to the 3640 using H.323, and it wants to transfer a call, you wouldn't be able to do this, since IOS cannot currently perform H.450.2 call transfers, if that is what the auto attendant is trying to do.
Can you provide more details on the auto attendant system, and how it tries to perform transfers? Thanks.
Yes... that is what I think we are trying to do.
Basically what is in Fig 3 of Chap 13 of the H323v2p2 doc, 'H.450 Call Transfer Without Consultation'.
The AA is the MMind AutoAttendant.
Rich, it will basically be the same kind of answer I gave to Andy. Until the CallManager starts to support the H.450.x supplementary services including H.450.2 Call Transfer, I don't know of a way to accomplish this will the MMind AutoAttendant -- note that I have not worked with that system so I know next to nothing about it other than what I have been told by you and Andy.
The only AutoAttendant systems I can suggest at this point which will work for transferring calls using CallManager are: Cisco Unity (Skinny Station protocol) and the Cisco IP-IVR/IP-AA which uses JTAPI to signal call redirection.
So all the documentation on the Cisco web site about IOS supporting H323v2p2 and H450 is 'premature' to put it as kindly as I can?
Leave out the CCM, can a 3640 running gateway code do a call transfer as per the docs I sited in the Case?
According to the documentation at:
The IOS gateway cannot be the transferring party (initiate), but it can be the transferred party or the transferred-to party, with a couple restrictions:
- blind transfer (not consultative)
- not gatekeeper controlled transfer
- not gatekeeper initiated transfer
The feature is intended in such a way that there is an H.323 terminal endpoint that is capable of initiating the H.450.2 transfer, and the IOS box can be the gateway used as the transferred or transferred-to party in the equation.
That being said, I have not yet had the pleasure of dealing with the H.450.2 feature implemented in IOS, since this falls outside the scope of current CallManager features.
But I would think a quick way to test the theory is to use the H.450.2 capable terminal (e.g. MMind AutoAttendant), and 2 IOS boxes, one to act as the PSTN gateway where the caller comes in, and the other to act as the user where the call gets transferred, such as a 2600 with an FXS interface and a phone.
Thanks.... you have been a help in interpreting the Cisco docs.... we may have actually done a successful transfer .... more testing today.
Intercom service between IP phones? Hi Dave, I am looking for a solution that will allow a person(s) to use the speaker on the 7960 phone as an intercom. They would like to dial a number that will open the speaker on all the assigned phones and announce a message to everyone, such as "Please evacuate the building, we have a fire alarm". I found one product called AutoAnswer that looks like it may be a good fit. Do you know if Callmanager will be providing this feature in the future.
My company is working on developing a product we currently have the Auto Answer feature, but it works better than most. If you want to email me offline you can I can get you what you need. We will have full intercom use of the phone developed within the next month
I have VG200 with PRI cards and am experiencing echo I have changed the db up and down and also changed the echo cancellation. The other aspect is that I have progress_ind commands in the dial-peers. Is there a fix for this today or does cisco plan to fix this?
Is it consistent echo throughout the call, or just the first few seconds?
Who is hearing the echo... is it the user on the IP phone side that hears themselves, or the PSTN users that hear themselves?
Is it with all numbers, just local, long distance, etc... the more you can isolate it to certain circumstances, the easier it will be to understand where the problem may lie.
The echo is coming from the IP Phone side the PSTN does not hear the echo. As far as when it occurs depends on the call sometimes it is all of the way through the conversation sometimes it is at the very begining of the conversation. I have tried to isolate it to certain numbers with no luck it is very unreliable. I am running 12.2.1 verison of IOS.
There have been some issues with 12.2(1) on the VG200 platform that may be contributing to the problem.
You might want to consider loading 12.1(5)T7 IOS on the VG200.
In the configuration, try going to the voice port(s) and using the commands input gain -3 and output attenuation 3.
These are just good dB levels to start the tuning process with, you will want to season to taste based on the results you get.
Note that you will want to tweak these numbers when there are no calls going through the gateway, and also that the changes you make will not take effect until you make a new call after the config change, it will not affect calls with an established audio path.
At one point I was running 12.1(5)T7, the same problems occured. I will start playing with the db settings again, but am not sure if it will help. Is 12.2.2 ok to try? This was supposed to fix the bugs in 12.2.1. Let me know what you think.