Cisco2851 H323 Called number transformation in Overlap mode.

Unanswered Question
Nov 24th, 2009

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Tableau Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Hi All,

I have a question regarding the ability to transform a called number coming in overlap mode. I know some posts have been already opened regarding this subsject but I was not able to really find a workaround for this scenario.

The number coming from the PSTN (Germany) switch is '555' and matches the dial-peer below:

-------------------------------------------------

dial-peer voice 5 pots

service ivr_niv1_site

incoming called-number 555

port 0/0/0:15

-------------------------------------------------

The reason of the troubles are due to the application of the tcl script application under the DP which does not like the prefix 555.

As you can see the prefix 555 is initially present and then the digits are coming one after one in overlap (exemple for called number 5551102531).

3w4d: //24109//Digi:/AFW_M_DigitCollect_Initiate: Overlap Setup sent '555'

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=5551

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=55511

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=555110

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=5551102

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=55511025

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=555110253

3w4d: //24109//Digi:/DigitCollect_DialPlanMatch: pattern offset=0, digits=5551102531

At first we were thinking if was due to the bug CSCsh27923 (The IOS is c3825-ipvoicek9-mz.124-3a.bin) but apparently not.

My question is : Is there a way once the dial-peer 5 matched with incoming called number '555' to remove from the called number this prefix ‘555’ in order to have at the end the number 1102531.

I have tested the translation-rule but it does not transform the Caller number. I have heard about using 'trunk group' and then apply the translation-profile to this trunk group. What do you think about it ?

Thanks a lot for your comments.

Regards

Karim

Telindus FRANCE

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Paolo Bevilacqua Tue, 11/24/2009 - 12:18

Regular Translation-profiles and rule should work.

Note incoming called-number, and translation-rule must reference the full number after overlap digits are received

krahmani323 Thu, 11/26/2009 - 05:05

Hello p.bevilacqua,

Thanks for your feedback.

In fact we have noticed the call routing via the TCL script was working fine from German mobile numbers but not from landlines (german provider is Colt).

The diffence noticed in the provider traces were some additional parameters (like higher layer compatibility) through the GSM call. Additionnaly, some ISUP (ISDN User-Part, SS7 signalization) is changed between a landline and GSM.

Anyway, from the debugs and in both cases the same number was submitted to the script (see below) but for one case it works and not for the other.

1102532T = 4=DC_MATCHED_DIALPLAN,

1102532T = 6=DC_INVALID_NUMBER

I cannot understand for the moment exaxctly why our TCL did not work for one case and not in the other case, but we have defined a kind of supplmentar «match-all» rule for the translation-profile applied to the DP (rule 2 /\(^.*)/ /\1/) and it worked in both cases.

Thanks for your tips.

Karim / Telindus France.

Paolo Bevilacqua Thu, 11/26/2009 - 05:58

Router doesn't care about any IE, only need to configure isdn overlap-receiving.

One must be familiar with the IOS logic to understand how it works also considering inbound DP has no concept of interdigit timout.

Actions

This Discussion