Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Redirection not working properly

I?ve got a strange redirect problem (or forward).

I?m using CME 4.1, calls come form a E1

My internal phones are 3 digits long (1XX in the detail)

The problem is this: if I redirect all the calls from a phone to an external number, the redirect works well if the number is like 002999999 or 00699999 and so on, and no works with number starting with only one 0 like 0347999999 or 033899999.

Here the relevant config lines:

!

voice translation-rule 2

rule 1 /^34\(.*\)/ /034\1/

rule 2 /^33\(.*\)/ /033\1/

rule 3 /^32\(.*\)/ /032\1/

rule 4 /^38\(.*\)/ /038\1/

rule 6 /^9\(..\)$/ /9\1/

rule 8 /^31\(.\)$/ /31\1/

rule 9 /\(.*\)/ /00\1/

!

voice translation-rule 4

rule 1 /1\(..\)/ /1234561\1

!

voice translation-profile trans-pri-in

translate calling 2

!

voice translation-profile trans-pri-out

translate calling 6

!

voice-port 0/0/0:15

translation-profile incoming trans-pri-in

translation-profile outgoing trans-pri-out

output attenuation -5

cptone IT

bearer-cap Speech

!

dial-peer voice 100 pots

destination-pattern 0T

incoming called-number 123456...

direct-inward-dial

port 0/0/0:15

!

telephony-service

dialplan-pattern 1 123456... extension-length 3

call-forward pattern .T

call-forward system redirecting-expanded

!

Any idea?

Thanks.

Marco.

16 REPLIES
New Member

Re: Redirection not working properly

No idea?

I've done lot of tests, but I cannot resolve this problem.

I can redirect calls only to fixed phones, not to mobile phones...

Hall of Fame Super Gold

Re: Redirection not working properly

Hi Marco,

I'm not sure, but that is the purpose of the translation rule? I think my CME installation can redirect OK to cellphones, of course when prepended with dial access of 0. It is much a probmle for you to use 0 in front of cellphone ?

New Member

Re: Redirection not working properly

Hello, and thanks for you reply.

First of all sorry, but I did a mistake when pasting the router configuration.

I have inserted the "voice translation-rule 4" instead of "translation-rule 6" that is used in "voice translation-profile trans-pri-out".

here is the "translation-rule 6":

voice translation-rule 6

rule 1 /^1/ /01/

The "voice translation-profile trans-pri-in" is used to prepend a 0 for the incoming calling number (ANI) so we can redial them directly from "unanswered call" or from "received call" from ephone local directory number.

The "voice translation-profile trans-pri-out" is needed to send the full number to the destination PSTN with the extension included.

In other words, without "trans-pri-out" the call receiver see the DN root as the calling number without the two last digits that represent the extension.

Let's suppose that my full phone number is 123456133 and I call you: without the traslation you will see 1234561 as calling number, not the 123456133 full number. Prepending a 0 in front of my full number you will see my full 123456133 number as calling number.

This is a restriction from the Telco operator.. or I think.

I hope now it's more clear the purpose of my translation rules.

A question about your CME configuration: do you have a PRI or BRI PSTN connection?

If a PRI, do you have DID numbers?

Back to the question:

in our tests we've tried to forward (with the "call-forward all phone#" command in the ephone-dn section) to three PSTN numbers. 2 of these are fixed phone number, 1 is a mobile one.

Moreover, the two fixed phone number are the same number, but a first setted up witch a dobule 0 in front of the number (i.e. 002xxxxxx) and the second with a single 0 in front of the number (i.e. 02xxxxx)

The mobile number was setted up prepending a single 0 (i.e. 0335xxxxx)

So, when the destination number for call-forward is the fixed PSTN number I receive the redirected call in both cases, i.e. with double or single 0 prepended to the number. In both cases I receive the root directory number, not the full number with extension. Again I see the 1234561 number not the 123456133 number with extension. Moreover the time used to setup the transfer seems to be faster when a single 0 is prepended to the number.

Keep in mind that the actual destination number for call redirect is another ISDN number, so the 2xxxxx number can be valid.

On other hands when the destination number for call-forward command is the mobile phone number (i.e. 0335xxxxxx) the call is dropped and the original caller can hear a busy signal at his end.

Without the prepending 0 the original caller can hear the operator reply messages that state "the number selected is not existent".

Note the behaviour of the ANI number the destination will see as like as the case we call outside without the "translation-profile outgoing trans-pri-out".

Thanks a lot, as usual.

Hall of Fame Super Gold

Re: Redirection not working properly

Hi Marco, now it's more clear.

first of all I can tell you that I have both BRI and PRI installations, with and without DID, and everything works fine with TI, fastweb, and all the cellphone operators.

Everything boils down to the way numbers are set and translations rules, etc.

So if you take "debug isdn q931" for a call where the extension is not passed correctly, or forward to a cellular that does not work, you will see very easily what is the problem.

A thing that I did and works nicely is to set ephone-dn without a physical ephone associate, and set a permanent CFA to a cellphone. So for example an user has extension 28, but will be reached at the cellphone by calling 48. In turn, if I want to forward all calls from my ephone to cellphone, I just enter 48 in the phone after pressing "CwdAll".

Hope this helps. Look at the debug output yourself and if still confused post, it here.

New Member

Re: Redirection not working properly

Hello Paolo,

We've done a test call with isdn debug activated.

I'll split my message in two, because it's too long.

First, the test with failed redirection.

The calling number is "12345678" (fixed phone), the called number "987654321" (fixed phone) on which there is a redirection to the number "3351234567" (mobile phone).

Apr 24 17:08:13.638: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x1800

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1838E

Preferred, Channel 14

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '12345678'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '987654321'

Plan:ISDN, Type:National

Apr 24 17:08:13.642: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0x9800

Channel ID i = 0xA9838E

Exclusive, Channel 14

Apr 24 17:08:15.646: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Calling num 0012345678

Apr 24 17:08:15.646: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Called num 3351234567

Apr 24 17:08:15.646: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x9800

Apr 24 17:08:15.646: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x020B

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9838F

Exclusive, Channel 15

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '0012345678'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '3351234567'

Plan:ISDN, Type:National

Apr 24 17:08:15.722: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x820B

Channel ID i = 0xA9838F

Exclusive, Channel 15

Apr 24 17:08:15.810: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x820B

Cause i = 0x8281 - Unallocated/unassigned number

Progress Ind i = 0x8288 - In-band info or appropriate now available

Apr 24 17:08:15.810: ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x818C

Apr 24 17:08:15.814: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x9800

Cause i = 0x8281 - Unallocated/unassigned number

Progress Ind i = 0x8288 - In-band info or appropriate now available

Apr 24 17:08:15.878: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x1800

Cause i = 0x82E4 - Invalid information element contents

Apr 24 17:08:15.878: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x9800

Apr 24 17:08:15.886: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x020B

Apr 24 17:08:15.950: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x820B

New Member

Re: Redirection not working properly

Here, a debug with a successfully redirection

The calling number is "12345678" (fixed phone), the called number "987654321" (fixed phone) on which there is a redirection to the number "021234567" (fixed phone):

Apr 24 17:28:52.079: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x5D00

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18383

Preferred, Channel 3

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '12345678'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '987654321'

Plan:ISDN, Type:National

Apr 24 17:28:52.083: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xDD00

Channel ID i = 0xA98383

Exclusive, Channel 3

Apr 24 17:28:54.087: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Calling num 0012345678

Apr 24 17:28:54.087: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Called num 021234567

Apr 24 17:28:54.087: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xDD00

Apr 24 17:28:54.087: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x020C

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9838F

Exclusive, Channel 15

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '0012345678'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '021234567'

Plan:ISDN, Type:National

Apr 24 17:28:54.175: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x820C

Channel ID i = 0xA9838F

Exclusive, Channel 15

Apr 24 17:28:55.891: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x820C

Progress Ind i = 0x8082 - Destination address is non-ISDN

Apr 24 17:28:55.899: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0xDD00

Progress Ind i = 0x8082 - Destination address is non-ISDN

Apr 24 17:28:59.319: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x5D00

Cause i = 0x8090 - Normal call clearing

Progress Ind i = 0x8288 - In-band info or appropriate now available

Apr 24 17:28:59.319: ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x18C

Apr 24 17:28:59.323: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x020C

Cause i = 0x8090 - Normal call clearing

Apr 24 17:28:59.327: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0xDD00

Apr 24 17:28:59.411: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x820C

Apr 24 17:28:59.411: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x020C

Apr 24 17:28:59.419: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x5D00

Thanks

New Member

Re: Redirection not working properly

Hello,

Maybe the cause is

"Cause i = 0x8281 - Unallocated/unassigned number".

It seems that the telco is not accepting the called number, or I'm wrong?

Thanks.

New Member

Re: Redirection not working properly

Hello,

Another update in relation to the problem.

By comparing the calls to the fixed number against the calls to the mobile number,

and other calls starting from ephones, we have noticed that the difference in called

party number plan and type.

So we have tried to translate the called number in outgoing calls

(translation-profile trans-pri-out) to change the type and plan.

We have created a generic rule and tested it with success. It work also with the

fixed called numbers.

Here is the changes done to the configuration:

voice translation-rule 8

rule 2 /\(.*\)/ /\1/ type national unknown

voice translation-profile trans-pri-out

translate called 8

telephony-service

no calling-number initiator

Note that after the last command, under telephony-service there is no calling-number

configuration at all.

If we add the command "calling-number local secondary" the configuration still works.

Now we got the call setup correctly but on the called side we see the DN root number

(without extension). Another behaviour observed is that when a mobile called party

reject the incoming callm, the original calling party continue to hear the ring tone, not the busy one.

Hall of Fame Super Gold

Re: Redirection not working properly

Hi Marco,

I'm a bit confused because with the masked numbers is hard to tell who is calling who.

Anyway, I think that by now you have understood that with ISDN, if the calling number falls in DID range, will be presented, else it will be replaced by the main number.

Now the question is, what behavior do you want ? Suppose extension 201 sets CFA to cellphone, what do you want to see, main number (1) or extension for redirected calls (201) ?

Note that rule 2 above can be rewritten

rule 2 // // type national unknown

New Member

Re: Redirection not working properly

Hi Paolo,

I'm not sure to understand what does make you confused: do you meant the number like "12345678" or like "12345678"?

If yes I explained the role of any single masked number at first sentence of the two debug output.

We want to see the extension for redirected calls, but it seems that the rule to translate calling number of the outgoing translation profile did not work properly.

It is the following translation-rule that simple prepend a 0 in front of the calling number starting with 1 (for example 12345678). In the meanwhile it work for calls that starts from ephones.

voice translation-rule 6

rule 1 /^1/ /01/

Yes, I understand the rule 2 rewritten. Thanks a lot.

In the test we have wrote it to cover only the case of mobile phone (i.e. /34\(.*\)/ /34\1/ type national unknown), and then we also tried it for all called number.

Marco.

Hall of Fame Super Gold

Re: Redirection not working properly

OK, I understand now.

The objective is to present calling number of the extension that has CF.

The thing is that there is no way of transforming the calling number based on called, and viceversa. Only a TCL script would be able to do this.

However, it should be doable, will test that and let you know.

Ciao!

Hall of Fame Super Gold

Re: Redirection not working properly

Hi Marco,

This was not so easy but I think I found a solution.

First of all, the command "calling-number" in "telephony-service" does not appear to do anything. The documentation has also a confusing reference to the TCL script for H.450. So, forget about it.

Instead, I used loopback-dn to achieve what was wanted. Add the following to your config:

ephone-dn 70

number 3......... <-- this is for 10 digits numbers beginning with 3

loopback-dn 71 prefix 0 <-- 0 is used to access outside line

caller-id local

ephone-dn 71

number 777 <-- put any number, it is not used

loopback-dn 70

On the phone on which you set call forward, enter the number directly without the digit to access line. This is preconfigured as 0 in the example above. The forwarding extension number should now be used as calling number to place the new call.

Note: there is a little problem with the number format. Because in "number" under "ephone-dn" the T does not work, you have to place as many dots as the length of the number you are forwarding to. In the above example, I configure for cellphone numbers of 3+7 digits, but there are also of 3+6 digits. So, if you have different type of numbers to forward to, you need to configure additional pairs of ephone-dn with loopback-dn.

I hope it is all clear and works for you. It took me some time to figure it out!

Please rate all useful posts using the scrollbox below!

New Member

Re: Redirection not working properly

Hello Paolo,

Thank you a lot for this advice.

I'll try this as soon as possible and I'll report you the results.

Marco.

New Member

Re: Redirection not working properly

Hi Paolo,

We have tried your solution and work for us too, with only one modification: we have substituted the number parameter under the ephone-dn 71 with a number that begin with 1 as the other ext numbers.

To reserve the use of assigned E.164 number we thinks that an appropriated translation rule can resolve this issue.

On other hands the solution can be expensive in term of use of ephone-dn, so we have to explain to the customer and let them decide.

Thanks a lot.

Marco.

Hall of Fame Super Gold

Re: Redirection not working properly

Hi,

What do you mean reserve the use of assigned e.164? What traslation-rule, for what ?

Ephone-dn are free! If you are forwarding to cellphone 6 and 7 digits you need two pairs, plus two more pairs for national number of 9 and 10 digits!

Not a large price for something that can't be done other way :)

New Member

Re: Redirection not working properly

Hi Paolo,

I think we missed something in relation to your solution.

To test the solution we have added at the IP phone ephone-dn from 1 to 49 the two ephone-dn 70 and 71 as you specified.

We have specified the 3xxxxxxx number as the pattern in ephone-dn 70 (not the 3........ pattern as you wrote), but this not change the behaviour, I think.

When we added CFA to the 3xxxxxxx number under ephone-dn 9 the call was successfully transferred to the mobile phone, but the calling number that appeared on the mobile phone was the DN root number (i.e. without extension). From debug q931 we seen that the calling number was 2xxxxx777 where 777 is just the number under ephone-dn 71.

So, changing the number under ephone-dn 71 from 777 to 177 (where 177 is an extension number) and testing again the CFA, the complete calling number appeared on the called mobile phone. But 177 is not the extension of the ephone-dn 9 which as the CF is set as noan.

The ephone-dn from 1 to 49 are dual-line so we cannot configure a loopback-dn under them.

You wrote that number 777 under ephone-dn 71 was not used, but we see it was not true for us.

So, when I wrote about reserving assigned E.164 number, I was referring to create a pair of loopback ephone-dn for the 49 (not for all but most of them) ephone-dn associated to them, with an extension that is it not used, reaching the 99 number assigned from Telco.

A workaround in order to fix the last issued was to still use 7xx number for all the loopback-dn "71" and with translation rule convert the 7xx to 1xx of the calling number for outbound call to the PSTN (i.e.: rule y /\(2.....\)7\(..\)/ /\11\2/ )

The number of ephone-dn will be enough for this implementation, but they are not unlimited, right?

Thanks again,

Marco.

629
Views
9
Helpful
16
Replies
CreatePlease to create content