Main site/ remote site/data center
- WAN connected/ VPN tunnels/Juniper FWs
- CUCM, 2851GW at Main
- Unity at data center
1) Inbound call rec'd at GW (Main site)
1.5) (3) Main listed number are CTI Route points that CFU to Unity.
2) Call is routed across WAN link to data center to Unity server where it is provided IVR treatment via a CallHandler with (6) Caller Input options.
3) If the calling party enters an extension of a phone at the remote site -the call will transfer to the point that the phone rings on the remote end, and the calling party hear call progress.
4) Calling party will get a fast busy
5) Called party (party that is transferred to) goes off-hook and hears fasy busy - no RTP.
6) Both parties hearing fast busy occurs when the call is "answered".
Same scenario as above but instead the caller selects an IVR options or times out and is routed to an operator (Transfer to subscriber extension).
1) Operators receives call
2) Calling party requests an extension at the remote office.
3) Transfer behavior is the exact same - operator hears call progress - then a fast busy as soon as the remote extension picks up.
4) The remotes phone rings but the called party hears fast busy when they attempt to answer the call.
- Calls and supplementary services between the main site and the remote work site - this behavior only happens when calls come through Unity
Thanks for you help - BrianL
Does the call fail when you dial from your IP phone to Unity, then enter in the extension of the remote site, etc. (problem 1). If it connects here, then you can narrow down the problem to possibly a codec issue.
Typically though, when a call comes into Unity, it will come in as certain codec. You are saying the remote gateway is h323, which means the 408-555-1212 comes into the GW, hits a dial peer, and routes to the CallManager. CallMangager has a CTI that routes to Unity.
From the Dial Peer to CUCM, do you have a defined codec? Possibly having a codec mis-match.
Unity will handle a unsupervised transfer back to CUCM. The call is basically back in CUCM "hands" and is going to route the rest of the request from Unity, Unity drops out. CUCM pushs the call to the IP phone. Call Signally is setup (or not setup, this is where you say it is failing) PSTN---to IP phone should be connected.
I would not worry about Unity too much. For a quick test, Change the CTI back to the remote IP phone. Does it work then?
Example: 408-555-xxxx route the XXXX to the CTI, then CFWDall on the line back an IP phone on the remote site. This will then tell if you Unity is causing the issue or it's between the CUCM and H323 gateway.
Seems to be a GW issue - I have attached my GW config. On my dial peers I am applying a voice class codec CMD. The codec specified in the class is G711ulaw - that is all I am set up to use.
I can place a DID number on the phone and when it rings in, same disconnect/fast behaviors on disconnect. Now what ???
So you are applying G711 to the Dial Peer for inbound. ON the IP phone, do you have some sort of Locations/regions setup for using Codecs to/from sites? Typically between sites, it's g729. Within the site, it's G711.
1) The voice class codec 1(includes a G711Ulaw) statement - and is applied to my VoIP dial-peers.
2) I have disabled the Advertise G722 at the device level and in the Service Parms.
3) After I reset a phone - I can make two to three outbound via the GW calls - and then then around the third or fourth call - the same disconnect behavior.
4) DNA tool confirms the routing should work
5) Regions and Locations G711 across the board.
Possibly run a debug voice ccapi inout on the router? We should be able to see why the call was disconnected in the debug logs.
Couple more questions:
was this working in the past,but suddenly stopped?
How is your H323 gateway configured on CUCM?
it could be possible the H323 gateway on CUCM does not have the Media Termination Point check box checked.
I usually do not use the "FastStarts" for inbound or outbound. Well, I never had to use them.
I would probably uncheck those, and "restart" or "reset" h323 gateway.
everything else looks fine. Possibly on the Gateway, take off all of this:
voice-class codec 1
voice-class h323 1
Leave the dial peer as plain as possible. It will still use G711 be default.
Transfer Number Is Null
Oct 16 17:10:08.916: //8597/804035591100/CCAPI/ccConferenceDestroy:
Conference Id=0xF76, Tag=0x0