[cisco-voip] Question regarding Calling Party Name manipulation in CUCM 7.13

[Andrew Dorsett]

CUCM has the ability to replace the calling party name on a SIP trunk in the
outbound direction.  There are several ways to implement the SIP trunk as a
hairpin in your call-flow.  The easiest method is to use CUBE with media
flow-around.
Andrew


On Wed, Oct 14, 2009 at 11:14 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

> As you've noted CUCM cannot change the calling party name.  What you are
> trying to do with the dummy DN forwarding the number is the way to go,
> except that on the lines receiving the calls you need to set them to display
> the redirected number (and hope this gets you the name) at the bottom of the
> line config (Forwarded Call Information Display).
> The other way you can do this is to use an app (CUAE, IPCCx, etc) to take
> the calls and set the name to whatever you want when it sends it to the
> destination.
>
> -Ryan
>
> On Oct 14, 2009, at 10:38 AM, Nate Aliberto wrote:
>
> Hi All,
>
> I have a rather interesting request supplied to me by a customer in the
> midst of a CUCM/Unity Connection 7.13 deployment, requiring that CUCM
> manipulate the calling party name of inbound calls being forwarded  from a
> call handler defined in Unity connection.
> Let me preface this by saying that I have advised against modifying either
> the incoming calling party number of the calling party name as the original
> calling party data would be lost and the ability to make call-backs etc is
> severely impaired, however for the sake of argument and to know if it is
> even possible……. I present this challenge.
>
> The calling scenario runs as follows:
>
> 1.       Call is received from the PSTN and routed to an Auto Attendant
> call handler in Unity Connection, where the caller is presented with options
> based on the purpose of their call (Sales, Service, Parts).
> 2.       Based on the option selected the call is to be routed to an
> operator extension for the department handling the call (as expected).
> 3.       While a single operator may be responsible for taking calls on
> behalf of multiple departments they are still required to answer the phone
> with an appropriate response (XYZ company Sales, XYZ company Parts etc.).
>
> Definitely a typical scenario for which under normal circumstances I would
> create one Directory number to serve as the attendant for each department
> defined above.  Separate line appearances for these DNs could then be
> assigned to the phones of those individuals providing coverage for each
> department.  When a call came into the Connection Call handler it would be
> routed to the appropriate directory number and the operator would then know
> the purpose of the call based on the line upon which it is received.
>
> My client however would like to avoid the deployment of multiple line
> appearances assigned to a phone and provide an indication of the call
> purpose using the “calling name” presentation of the incoming call.  For
> Example:  If a  call came into the operator from the Connection Call Handler
> destined for Sales the call would appear on the phone display as being from
> “Sales” (or another friendly name).  I’ve attempted to achieve this in a
> test scenario using a calling party transformation pattern to translate the
> calling party number to an internally defined DN, for which the Internal
> Caller ID is defined as “Sales”.  While the call is routed and calling party
> number is translated as expected the calling party name does not change.
>
> Ideally this would be simpler if I could somehow display the forwarding
> station Number and Name to the operator rather than the original calling
> party information but I’m not sure how to achieve that either.
>
> Any advice/suggestions would be greatly appreciated.
>
> Nate
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091014/e083a1e3/attachment.html>