[cisco-voip] RDNIS and Original Called Number IE

Thu Jun 21 18:29:59 EDT 2012

This is a long shot but I remember there is a setting in ent parms or svc parms tells cucm to pass caller id to unity...  again I think you prolly set this ... 
________________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] on behalf of Eric Pedersen [PedersenE at bennettjones.com]
Sent: Thursday, June 21, 2012 6:01 PM
To: Ryan Ratliff
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] RDNIS and Original Called Number IE

Looking at the SDI logs, CUCM looks like it's ignoring the OCN IE.  The originalCalledParty sent to Unity in the SCCP CallInfo is the ISDN Called Party Number.

I'm pretty sure I tried it before checking "Redirecting Number IE Delivery – Inbound ". I could try disabling it again one evening.

From: Ryan Ratliff [mailto:rratliff at cisco.com]
Sent: 21 June 2012 12:17 PM
To: Eric Pedersen
Cc: Ted Nugent; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] RDNIS and Original Called Number IE

What do the ccm traces show we are doing with the OCN when it hits CUCM?

Have you tried disabling the "Inbound redirecting IE delivery" on the PRI in CCMAdmin?  If we aren't looking for the RDN IE then maybe we'll be better about passing along OCN.

-Ryan

On Jun 21, 2012, at 1:55 PM, Eric Pedersen wrote:

The redirect number is making it to the central site, but CUCM isn't passing it along to Unity Connection.

i.e: (I changed the actual phone numbers)
991449: Jun 21 11:47:56.505 MDT: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0141
                Bearer Capability i = 0x8090A2
                                Standard = CCITT
                                Transfer Capability = Speech
                                Transfer Mode = Circuit
                                Transfer Rate = 64 kbit/s
                Channel ID i = 0xA9838F
                                Exclusive, Channel 15
                Display i = 0xB1, 'Pedersen, Eric'
                Calling Party Number i = 0x2183, '7805551212'  (original calling number)
                                Plan:ISDN, Type:National
                Called Party Number i = 0xA1, '4035551212' (VM pilot)
                                Plan:ISDN, Type:National
                Original Called Number i = 0x00000281, '7805551213'  (VM mailbox number)
                                Plan:Unknown, Type:Unknown

When I forward the same call to a SIP gateway, the GW does this:
067285: Jun 20 20:46:02.990 MDT: ISDN Se0/0/0:23 Q931: extract_redirect_orig_called_ie: IE type orig called num 7805551213 reason 15 cnt 0 plan 0 type 0 pres 0

And the SIP invite from the GW to CUCM has:
Diversion: <sip:7805551213 at 10.16.64.1>;privacy=off;reason=unconditional;screen=no

And then it gets to the correct mailbox. So it seems to me that the issue is with CUCM and the MGCP GW.  I've been considering changing the central GW to SIP anyway, so maybe this is a reason to do it.

Eric

From: Ted Nugent [mailto:tednugent73 at gmail.com]
Sent: 21 June 2012 11:27 AM
To: Eric Pedersen
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] RDNIS and Original Called Number IE

In my experience with this all providers from the remote site to the Unity pilot  location ALL need to support RDNIS, which is not always feasible.
It's been a while but I would look into sending the digits inband

 dial-peer voice 10 pots
 destination-pattern 19195551212
 port 0/0/0:23
 forward-digits extra inband
On Thu, Jun 21, 2012 at 12:06 PM, Eric Pedersen <PedersenE at bennettjones.com<mailto:PedersenE at bennettjones.com>> wrote:
We're running CUCM 8.6(2).21900-5.

When one of our remote sites goes into SRST, I would like to be able to have voicemail survivability by forwarding no-answer/busy to the Unity pilot number at our central site.  We're using DMS-100 PRIs at both locations and I can see in the ISDN debugs that the redirect number is getting correctly passed by the telco in the ISDN Setup Original Called Number IE.  CUCM however is not passing on the Original Called Number IE contents to Unity Connection.  I have "Redirecting Number IE Delivery – Inbound" checked on the GW config, but that's not the IE that's being used in the Setup; I assume that's because it's a DMS-100 PRI.

The remote GW is SIP so as an experiment I tried forwarding a call there. This GW correctly takes the contents of the Original Called Number IE and puts it in the Diversion Header which CUCM uses as the RDNIS so it looks like I have a problem with my central MGCP GW.

Am I missing something in my configuration, or does CUCM not support the Original Called Number IE?

Thanks,
Eric

The contents of this message may contain confidential and/or privileged

subject matter. If this message has been received in error, please contact

the sender and delete all copies. Like other forms of communication,

e-mail communications may be vulnerable to interception by unauthorized

parties. If you do not wish us to communicate with you by e-mail, please

notify us at your earliest convenience. In the absence of such

notification, your consent is assumed. Should you choose to allow us to

communicate by e-mail, we will not take any additional security measures

(such as encryption) unless specifically requested.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

The contents of this message may contain confidential and/or privileged

subject matter. If this message has been received in error, please contact

the sender and delete all copies. Like other forms of communication,

e-mail communications may be vulnerable to interception by unauthorized

parties. If you do not wish us to communicate with you by e-mail, please

notify us at your earliest convenience. In the absence of such

notification, your consent is assumed. Should you choose to allow us to

communicate by e-mail, we will not take any additional security measures

(such as encryption) unless specifically requested.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

This message w/attachments (message) is solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any products.