cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6954
Views
0
Helpful
2
Replies

Restrict Calling Party Number (CLIR on IOS gateway)

Lukas Auer
Level 4
Level 4

Hi everybody,

I have a problem with mobile connect calls:

- External PSTN user calls one of my mobility-enabled DID numbers (418302001), but doesn't send calling party number (CLIR)

Channel ID i = 0xA98382

                Exclusive, Channel 2

Calling Party Number i = 0x00A3, N/A

                Plan:Unknown, Type:Unknown

Called Party Number i = 0xA1, '418300001'

                Plan:ISDN, Type:National

- CUCM forks the call and sets up the second call to the remote destination, in this case a cell phone (0797900000).

  For this second mobility call, CUCM transmits no Calling Party Number (since it didn't receive one with the first call).

  In the isdn q931 debug you only see the Called Party Number, but no Calling Party Number at all.

Channel ID i = 0xA98381

                Exclusive, Channel 1

Called Party Number i = 0x80, '0797900000'

                Plan:Unknown, Type:Unknown

As soon as this call hits the PSTN, my provider adds the PRI main number as calling party number.

The mobility user now gets a mobility call from the main number instead of one that shows "restricted".

What I can do is add a translation-rule on the H.323 gateway which adds some number (418300990):

voice translation-rule 300
  rule 1 /^$/ /418300999/ type unknown national plan unknown isdn
!
voice translation-profile mobility
translate calling 300


But that doesn't really help me. What I really need to do is set the calling party number to restricted / set the CLIR bit.

Any ideas on how this could be achieved?

Or maybe there is a way on the CUCM (v7.1.2)?

Thanks.

lukas

1 Accepted Solution

Accepted Solutions

Hi Lucas,

I ran in to exactly the same problem some time ago, this is how I solved it. It requires a H.323 VGW.

Prefix calling number out of the UCM to the GW used for routing the call to the RD. It can be anything, it will only be used internal in the VGW. I used 890 as the prefix.

Setup two incoming voice dial peers that match on answer-address 890 or 890[0-9]. The one that only match on 890 has clid restrict.

dial-peer voice 100 voip

description Outgoing calls from CM

answer-address 890[0-9]

voice-class codec 1

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 200 voip

description Outgoing calls from CM, match "null" and hide calling nr

answer-address 890

voice-class codec 1

dtmf-relay h245-alphanumeric

clid restrict

no vad

Then on the outgoing pots dial-peer remove the prefix on the calling number.

dial-peer voice 10 pots

description Outgoing calls to MDA (Telenor)

translation-profile outgoing Remove_Prefix_From_CM

destination-pattern 07[0,3,6].......

no digit-strip

port 0/0/0:15

voice translation-rule 110

rule 1 /^890\(.*\)/ /\1/

!

!

voice translation-profile Remove_Prefix_From_CM

translate calling 110

Then on the voice port in the outgoing direction do whatever other digit manipulation that could be needed for outgoing calls, including a last rule that will be matched if no other previous has been matched.

voice translation-rule 100

rule 1 /^00/ //

rule 2 /^\(50...$\)/ /4063\1/

rule 3 /^\(51[0-4]..$\)/ /4063\1/

rule 4 /^8....$/ /406350000/

rule 5 /^$/ /0/ type any national plan any isdn *

*This is the last rule that is used to set something as ANI. Without it the main number was still shown in my case. Remember that clid is restricted, so this could be whatever.

voice translation-profile Out_2_MDA

translate calling 100

voice-port 0/0/0:15

translation-profile outgoing Out_2_MDA

cptone SE

There is also a service parameter that could be changed for the unknown number, but I didn’t want to go that way, therefor this some what complicated way of doing it, mainly because this was a more specific solution that just affected this call routing scenario.

Best of luck.



Response Signature


View solution in original post

2 Replies 2

Hi Lucas,

I ran in to exactly the same problem some time ago, this is how I solved it. It requires a H.323 VGW.

Prefix calling number out of the UCM to the GW used for routing the call to the RD. It can be anything, it will only be used internal in the VGW. I used 890 as the prefix.

Setup two incoming voice dial peers that match on answer-address 890 or 890[0-9]. The one that only match on 890 has clid restrict.

dial-peer voice 100 voip

description Outgoing calls from CM

answer-address 890[0-9]

voice-class codec 1

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 200 voip

description Outgoing calls from CM, match "null" and hide calling nr

answer-address 890

voice-class codec 1

dtmf-relay h245-alphanumeric

clid restrict

no vad

Then on the outgoing pots dial-peer remove the prefix on the calling number.

dial-peer voice 10 pots

description Outgoing calls to MDA (Telenor)

translation-profile outgoing Remove_Prefix_From_CM

destination-pattern 07[0,3,6].......

no digit-strip

port 0/0/0:15

voice translation-rule 110

rule 1 /^890\(.*\)/ /\1/

!

!

voice translation-profile Remove_Prefix_From_CM

translate calling 110

Then on the voice port in the outgoing direction do whatever other digit manipulation that could be needed for outgoing calls, including a last rule that will be matched if no other previous has been matched.

voice translation-rule 100

rule 1 /^00/ //

rule 2 /^\(50...$\)/ /4063\1/

rule 3 /^\(51[0-4]..$\)/ /4063\1/

rule 4 /^8....$/ /406350000/

rule 5 /^$/ /0/ type any national plan any isdn *

*This is the last rule that is used to set something as ANI. Without it the main number was still shown in my case. Remember that clid is restricted, so this could be whatever.

voice translation-profile Out_2_MDA

translate calling 100

voice-port 0/0/0:15

translation-profile outgoing Out_2_MDA

cptone SE

There is also a service parameter that could be changed for the unknown number, but I didn’t want to go that way, therefor this some what complicated way of doing it, mainly because this was a more specific solution that just affected this call routing scenario.

Best of luck.



Response Signature


hey roger,

thanks so much for your super quick reply, sounds like a great idea!

I will definitly look into this. Not sure whether I can try this in the next few days since it does come with some call routing/dial-peer implications and I'm facing this problem in a live system. I'll get back to you/your post and rate it as soon as I know more.

lukas.