cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1789
Views
0
Helpful
9
Replies

CME Call forward All Issue

alvin1976
Level 1
Level 1

Hello all, I've configured CME4.1 in a 2851 with CUE 2.3. I'm facing some issues with call forwards. Here's the scenario:

Call-forward-All configured on IP Phone A to a external landline or handphone number-

a) IP Phone B calling IP Phone A, call forward works. Land line or handphone receives call.

b)External handphone call DID of IP Phone A. Calling phone can hear ring tone, but the landline/handphone which was forwarded to from IP Phone A is not ringing. After a while, the ringing tone on the calling phone stops and we get slow engage tones which is not our usual telco engage tone in S'pore.

If the targeted call-forward-all number is configured as an internal extension of another IP Phone, everything works fine.

Here's the configuration in the attached file.

Any idea what the issue is?

Thanks

Alvin

1 Accepted Solution

Accepted Solutions

Alvin,

my bad. I had you modify the calling number plan/type, but left the called number plan/type (that is even more important), unchanged.

You can do that in three ways, pick the one you like better:

- under interface e0/0/0:15, "isdn map address ... type unknown"

or, under the outgoing DP, "numbering-type unknown"

or, a translation-rule outgoing for called, matching everything like: // // type any unknown. You can apply it either at DP or voice-port level.

Let us know if it works!

View solution in original post

9 Replies 9

paolo bevilacqua
Hall of Fame
Hall of Fame

Hello Alvin,

This can be an issue with Q931 messages and IE on the PRI. Now, you have configured:

voice call send-alert

voice call convert-discpi-to-prog

voice rtp send-recv

Did you configured these because of a problem, or just because these commands are in some troubleshooting document ?

I need to ask this before be proceed further with the usual debug of "isdn q931".

you got me there, i've no idea this came into the config. probably configured by fellow colleagues when they are troubleshooting other issues. meanwhile here's the debug isdn q931:

132350: Jun 15 17:08:15.793 SGT: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0034

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98382

Exclusive, Channel 2

Calling Party Number i = 0x4183, '96800021'

Plan:ISDN, Type:Subscriber(local)

Called Party Number i = 0xC1, '63057340'

Plan:ISDN, Type:Subscriber(local)

132351: Jun 15 17:08:15.809 SGT: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8034

Channel ID i = 0xA98382

Exclusive, Channel 2

132352: Jun 15 17:08:15.817 SGT: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1

, Calling num 63057373

132353: Jun 15 17:08:15.817 SGT: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1

, Called num 90298053

132354: Jun 15 17:08:15.817 SGT: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x098C

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839C

Exclusive, Channel 28

Calling Party Number i = 0x4183, '63057373'

Plan:ISDN, Type:Subscriber(local)

Called Party Number i = 0xC1, '90298053'

Plan:ISDN, Type:Subscriber(local)

132355: Jun 15 17:08:16.145 SGT: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x898C

Channel ID i = 0xA9839C

Exclusive, Channel 28

132356: Jun 15 17:08:16.545 SGT: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x898C

Cause i = 0x829C - Invalid number format (incomplete number)

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

132357: Jun 15 17:08:16.549 SGT: ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Postpon

e sending RELEASE for callid 0x890D

132358: Jun 15 17:08:16.553 SGT: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8034

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

132359: Jun 15 17:08:20.745 SGT: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0034

Cause i = 0x8090 - Normal call clearing

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

132360: Jun 15 17:08:20.749 SGT: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x8034

132361: Jun 15 17:08:20.753 SGT: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x098C

132362: Jun 15 17:08:20.833 SGT: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0034

132363: Jun 15 17:08:20.873 SGT: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x898C

Oh yeah, you've probably noticed that my outbound calling number has been translated to my PRI trunk number 63057373.

Hi,

The problem appears to be:

Cause i = 0x829C - Invalid number format(incomplete number)

Please make a call with debug to 90298053, either directly or via the forwarded extension, so we can compare the difference in the way router is building the setup message.

The translation you applied is correct. There is a technique to make so the calling number is the DID of the extension forwarding, but beside you may not want this, it's a bit more complicated.

OK, I've done the debug again, this time calling the number directly from the phone configured with the call-forward-all function.

132505: Jun 15 18:01:12.997 SGT: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1

, Calling num 63057340

132506: Jun 15 18:01:13.001 SGT: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1

, Called num 90298053

132507: Jun 15 18:01:13.001 SGT: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x09CE

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839C

Exclusive, Channel 28

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

Calling Party Number i = 0x0180, '63057340'

Plan:ISDN, Type:Unknown

Called Party Number i = 0x81, '90298053'

Plan:ISDN, Type:Unknown

132508: Jun 15 18:01:13.325 SGT: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x89CE

Channel ID i = 0xA9839C

Exclusive, Channel 28

132509: Jun 15 18:01:17.405 SGT: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x89CE

132510: Jun 15 18:01:20.137 SGT: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x89CE

Date/Time i = 0x07060F1201

132511: Jun 15 18:01:20.137 SGT: %ISDN-6-CONNECT: Interface Serial0/0/0:27 is now connected to 90298053 N/A

132512: Jun 15 18:01:20.141 SGT: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x09CE

132513: Jun 15 18:01:22.017 SGT: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x89CE

Cause i = 0x8090 - Normal call clearing

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

132514: Jun 15 18:01:22.017 SGT: %ISDN-6-DISCONNECT: Interface Serial0/0/0:27 disconnected from 90298053 , call lasted 1 seconds

132515: Jun 15 18:01:22.017 SGT: ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x894F

132516: Jun 15 18:01:28.225 SGT: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8 callref = 0x89CD

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

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

Ok, the router is copying plan/type for outgoing as received on incoming. But, type "subscriber" is not accepted.

Try making your voice translation-rule 30 as:

rule 1 /^1\(73[4-9][0-9]\)/ /6305\1/ type any unknown

rule 2 /.*/ /63057373/ type any unknown

I also think you do not need the three "voice"commands above mentioned, but that's another issue.

Let us know if it works and do not forget to rate useful posts!

hi, thanks for your advise, but still no luck.. I've removed the 3 configurations as you have pointed as well as amended the translation pattern..oh yeah after removing the 3 lines, instead of getting a ringing tone, this time it is just a Telco engage tone. my debug of isdn q931 still shows similar results:

132637: Jun 15 22:44:26.488 SGT: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callr

ef = 0x0048

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839D

Exclusive, Channel 29

Calling Party Number i = 0x4183, '90298053'

Plan:ISDN, Type:Subscriber(local)

Called Party Number i = 0xC1, '63057340'

Plan:ISDN, Type:Subscriber(local)

High Layer Compat i = 0x9181

132638: Jun 15 22:44:26.500 SGT: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8048

Channel ID i = 0xA9839D

Exclusive, Channel 29

132639: Jun 15 22:44:26.508 SGT: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Calling num 63057373

132640: Jun 15 22:44:26.508 SGT: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1, Called num 90298053

132641: Jun 15 22:44:26.508 SGT: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0A08

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839F

Exclusive, Channel 31

Calling Party Number i = 0x0183, '63057373'

Plan:ISDN, Type:Unknown

Called Party Number i = 0xC1, '90298053'

Plan:ISDN, Type:Subscriber(local)

High Layer Compat i = 0x9181

132642: Jun 15 22:44:26.840 SGT: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8A08

Channel ID i = 0xA9839F

Exclusive, Channel 31

132643: Jun 15 22:44:27.244 SGT: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x8A08

Cause i = 0x829C - Invalid number format (incomplete number)

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

132644: Jun 15 22:44:27.244 SGT: ISDN Se0/0/0:15 Q931: call_disc: PI received in

disconnect; Postpone sending RELEASE for callid 0x8989

132645: Jun 15 22:44:27.272 SGT: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x8048

Cause i = 0x829C - Invalid number format (incomplete number)

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

132646: Jun 15 22:44:27.412 SGT: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x0048

Cause i = 0x82E31E - Information element not implemented

132647: Jun 15 22:44:27.412 SGT: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8048

132648: Jun 15 22:44:27.420 SGT: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x0A08

132649: Jun 15 22:44:27.512 SGT: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8A08

Alvin,

my bad. I had you modify the calling number plan/type, but left the called number plan/type (that is even more important), unchanged.

You can do that in three ways, pick the one you like better:

- under interface e0/0/0:15, "isdn map address ... type unknown"

or, under the outgoing DP, "numbering-type unknown"

or, a translation-rule outgoing for called, matching everything like: // // type any unknown. You can apply it either at DP or voice-port level.

Let us know if it works!

It's working! The help is greatly appreciated! am I right to assume that when you set the numbering-type to any unknown, you are in fact specifying a wildcard to match any type of offered and presented numbering-type?

Also, here's what is another task for me relating to this. I've removed the 2nd rule of the voice translation hoping that when handphone A calls the DID of IP Phone, as it redirects to another Handphone B, handphone B will be able to see the calling number as the call-forwarding IP Phone DID. I do think my Telco prevents the CME from forwarding the original calling number of Handphone A to be shown in Handphone B. That's why i'm seeing the trunk number as the calling number. Any fantastic ways to send the caller-id of the IP Phone to the forwarded number?

Glad to know it worked. The "numbering-type" under DP will simply set the desired type for all and any call going out that DP.

Now for your other question, you are correct that is not possible to present the original calling number, because it does not belong to the numbers assigned to you by telco.

And yes, there is a fantastic way to send instead the DID of the ephone-DN on which the call-forwarding has been set. This uses the little-know loopback-dn feature. See:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=IP%20Telephony&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dde396e/11#selected_message

Beside the solution that I gave, you will find some more in-depth discussion with Marco Pizzi that is another CME hardcore adept.

Thanks for the nice rating and good luck!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: