call transfer failing to fxs port

[admin_2]

whenever I transfer (either supervised or release) from Unity to an analog set hanging off an FXS port in a 3600 router, the call either generates a partial ring and then vm or results in a transfer directly to vm (oddly, it works on the first or second call, then fails from then on!). We do not have this problem when transferring directly from another extension to the FXS port (not involving Unity). We are using a subscriber box to ring the analog extension (which is carried out on a plant floor by a mobile manager)and ideally want to recall the call to vm in the event of rna.<br><br><br>

[#2]

Make sure that the 3640 has a dial-peer(s) configured with a destination-pattern that matches the extension of the calling Unity port. For instance, if the Unity port extension numbers are 1001-1004, a dial-peer destination pattern of 100. should do the trick. After that, make sure the dial-peer has the following settings enabled:

dtmf-relay h245-alphanumric
codec g711ulaw

The Unity ports might be inheriting the default voip codec (g729) on the router when trying to call the FXS port. The creation and configuration of dial-peers for Unity should cover that. By default, Unity isn't going to support g729, but the IP phones do. That would explain why an IP phone can do it, but Unity cannot.

If you are dealing with partitions and calling search spaces, make sure that Unity is in the same calling search space as the H.323 gateway you created for the 3640.

Steve Olivier
Software Engineer
Cisco Systems

[#3]

I forgot to mention, for your supervised transfer to the FXS port to work, you are going to want to get your hands on TSP 32. Among many fixes, it fixes CSCae07925 (Outgoing calls through gateway are set to "connected" while call is still alerting).

Steve Olivier
Software Engineer
Cisco Systems

[#4]

Steve, we continue to experience the same issue and I have escalated a tac case including a ccm log. As it is now, the call can be "connected", but no talk path either way. Supervised just rings and rings. The tsp is 3.1.213.0. Recommendations for finding tsp 3.2? Any other ideas?

[#5]

Yeah, anything under TSP 32 is going to turn any supervised transfer into a release transfer when the transferred-to party is on the other side (or, in your case...on) the gateway. That is why the phone rings and rings. To get that TSP, cruise here:

http://www.cisco.com/cgi-bin/tablebuild.pl/unity

If there is no talk-path (the FXS port can answer the call without getting reorder), I would bet there is a gateway configuration issue. I'd be curious to see what the config looks like on that router.

Steve Olivier
Software Engineer
Cisco Systems

[jschless]

Hey Steve!

I am working with Roger on this issue and he had fogotten to mention that this Call Manager is on a ICS 7750. We checked the version and noticed the Call manager is actually on ver 3.0.3. Roger is planning on upgrading the ICS to ver 1.1.0, which will bring the Call manager portion to 3.0.8.

The question to you is, will TSP 32 be effective on this ICS platform? I am guessing that it will, but I thought we'd throw this by you.
Thanks

Jeff Schlesser
CSE
TAC Engineer
408-527-4204

[kechambe]

Yeah, it will be fine Jeff. Once he upgrades the bundle have him put the new TSP on.

Keith


Keith Chambers
Customer Support Engineer
Cisco Systems
kechambe@cisco.com