Solved: UC520: translation of externel number does not working

Philipp Hoeffker · ‎11-04-2010

Hi,

The feature "clip no screening" is activated by our ISP so we can change the externel number. I have implement a translation rule and map it on the outgoing dial-peer. But it is not working, can someone help me ?

Here the running config:

dksingh · ‎11-05-2010

Did u test the translation rule?

Did u run isdn debug to see what is the CLID, type/plan, screening/presentation ind. being sent out?

View solution in original post

dksingh · ‎11-08-2010

I see that you have masked the CNG party number in the debugs with xxx

Calling Party Number i = 0x0080, 'xxx'
Plan:Unknown, Type:Unknown

Is that the correct string for calling number (as per the traslation) that we

are putting out on the wire ?

If yes, then is the caller party seeing something different from above?

If that's true, then your telco is overwriting the CLID.

Curious if have u tried to change the plan and type to ISDN/National from

Unknown/Unknown ?

View solution in original post

dksingh · ‎11-08-2010

hmm...your telco should be able to tell you if they are overwriting the

CLID if the destination party is seeing something other than what the

GW debugs show.

Atleast they can tell you what they are passing to the other side if there

are other telco/carriers involved.

You may try modifying your xlation to change the plan/type and see if

it makes any diff but not much we can do as once we put it out on wire,

its out of our control.

example:

rule 1 /1234/ /5678/ type any isdn plan any national

View solution in original post

dksingh · ‎11-04-2010

Did u try Router#test voice translation-rule CLI to check

if the xlation checks out ?

You can also try applying the xlation profile directly under voice port.

Appears u r using BRI interfaces for outbound, can u run deb isdn q931

and check what is the GW sending in outgoing q931 SETUP?

Philipp Hoeffker · ‎11-05-2010

Ok i have map the outgoing Profile on the voive-ports 0/1/0 and 0/1/1 but nothing happend.

dksingh · ‎11-05-2010

Did u test the translation rule?

Did u run isdn debug to see what is the CLID, type/plan, screening/presentation ind. being sent out?

Philipp Hoeffker · ‎11-05-2010

The Trasnlation-rule works as planed.

Philipp Hoeffker · ‎11-08-2010

So now i have the debug

TM-UC520>enable
Password:
Password:
TM-UC520#debuf   g isdn q931
debug isdn q931 is        ON.
TM-UC520#
Nov 8 09:46:27.722: ISDN BR0/1/1 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num xxx
Nov 8 09:46:27.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:27.778: %LINK-3-UPDOWN: Interface BRI0/1/1, changed state to up
TM-UC520#
Nov 8 09:46:28.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
TM-UC520#
Nov 8 09:46:29.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:30.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
TM-UC520#
Nov 8 09:46:31.726: ISDN BR0/1/1 Q931: Ux_DLRelInd: DL_REL_IND received from L2
Nov 8 09:46:31.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:31.730: ISDN BR0/1/1 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num xxx
Nov 8 09:46:31.734: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
TM-UC520#
Nov 8 09:46:32.734: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:33.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:33.726: ISDN BR0/1/1 Q931: Ux_DLRelInd: DL_REL_IND received from L2
Nov 8 09:46:33.730: ISDN BR0/1/0 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num xxx
Nov 8 09:46:33.734: ISDN BR0/1/0 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Called num yyy
Nov 8 09:46:33.734: ISDN BR0/1/0 Q931: TX -> SETUP pd = 8 callref = 0x49
    Bearer Capability i = 0x8090A3
        Standard = CCITT
        Transfer Capability = Speech
        Transfer Mode = Circuit
        Transfer Rate = 64 kbit/s
    Channel ID i = 0x81
        Preferred, B1
    Progress Ind i = 0x8183 - Origination address is non-ISDN
    Calling Party Number i = 0x0080, 'xxx'
        Plan:Unknown, Type:Unknown
    Called Party Number i = 0x80, 'xxx'
        Plan:Unknown, Type:Unknown
TM-UC520#
Nov 8 09:46:34.706: ISDN BR0/1/0 Q931: RX <- SETUP_ACK pd = 8 callref = 0xC9
    Channel ID i = 0x89
        Exclusive, B1
Nov 8 09:46:34.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:35.726: ISDN BR0/1/1 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive
Nov 8 09:46:35.726: ISDN BR0/1/1 Q931: L3_ShutDown: Shutting down ISDN Layer 3
Nov 8 09:46:35.726: ISDN BR0/1/1 Q931: L3_ShutDown: Shutting down ISDN Layer 3
TM-UC520#
Nov 8 09:46:35.778: %LINK-3-UPDOWN: Interface BRI0/1/1, changed state to down
TM-UC520#
Nov 8 09:46:40.294: ISDN BR0/1/0 Q931: RX <- CALL_PROC pd = 8 callref = 0xC9
Nov 8 09:46:40.358: ISDN BR0/1/0 Q931: RX <- PROGRESS pd = 8 callref = 0xC9
    Progress Ind i = 0x8288 - In-band info or appropriate now available
Nov 8 09:46:40.398: ISDN BR0/1/0 Q931: RX <- ALERTING pd = 8 callref = 0xC9
TM-UC520#
Nov 8 09:46:43.726: ISDN BR0/1/1 Q931: L3_ShutDown: Shutting down ISDN Layer 3
TM-UC520#
Nov 8 09:46:46.850: ISDN BR0/1/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x49
    Cause i = 0x8090 - Normal call clearing
Nov 8 09:46:47.130: ISDN BR0/1/0 Q931: RX <- RELEASE pd = 8 callref = 0xC9
    Facility i = 0x91A115020106020122300DA1053003020100820101830100
        Protocol Profile = Remote Operations Protocol
        0xA115020106020122300DA1053003020100820101830100
        Component = Invoke component
            Invoke Id = 6
            Operation = AOCDChargingUnit
Nov 8 09:46:47.134: ISDN BR0/1/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x49
xx-UC520#

dksingh · ‎11-08-2010

I see that you have masked the CNG party number in the debugs with xxx

Calling Party Number i = 0x0080, 'xxx'
Plan:Unknown, Type:Unknown

Is that the correct string for calling number (as per the traslation) that we

are putting out on the wire ?

If yes, then is the caller party seeing something different from above?

If that's true, then your telco is overwriting the CLID.

Curious if have u tried to change the plan and type to ISDN/National from

Unknown/Unknown ?

Philipp Hoeffker · ‎11-08-2010

I had today a call with our telco service. The Problem with the Bri 0/1/1 is the Problem of the Telco.

Calling Party Number i = 0x0080, 'xxx'
Plan:Unknown, Type:Unknown

Yes this is the translated Nummer and so teh rule work as aspektet. But our Telco say the feature that we can determine the calling Number is activ.

I applied the rule and the profile nothing more. I put no finger on any other parameters of the Running Config. Whre i can find a solution to resolve this Problem.

I was throwen into this Problem because the previous Admin has left the company .... :-)

dksingh · ‎11-08-2010

hmm...your telco should be able to tell you if they are overwriting the

CLID if the destination party is seeing something other than what the

GW debugs show.

Atleast they can tell you what they are passing to the other side if there

are other telco/carriers involved.

You may try modifying your xlation to change the plan/type and see if

it makes any diff but not much we can do as once we put it out on wire,

its out of our control.

example:

rule 1 /1234/ /5678/ type any isdn plan any national

Philipp Hoeffker · ‎11-09-2010

A Telco technican

was today @Company to solve the missing Line problem. I asked him to look at our outgoing data. After a logging and a call he say we have to drop the first Zero and Change the Typ of Number.

--->Our Rule works but in the Field "Type of Number" is the word "national" missing

Calling Party Number i = 0x0080, 'xxx' -----> Calling Party Number i = 0x0080, 'xxx'
Plan:Unknown, Type:Unknown ------> Plan:Unknown, Type:national

But when I mdify the xrule to :

rule 1 /.*/ /without zero xxx/ type any national plan isdn national

the rule match with nothing

Philipp Hoeffker · ‎11-10-2010

so Problem solved thanks for your anwsers.

rule 1 /^.*/ /xxx/ Type unknown national

..... syntax :-)