11-04-2010 02:04 PM - edited 03-16-2019 01:44 AM
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:
Solved! Go to Solution.
11-05-2010 04:33 AM
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?
11-08-2010 08:10 AM
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 ?
11-08-2010 10:41 AM
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
11-04-2010 08:06 PM
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?
11-05-2010 03:40 AM
Ok i have map the outgoing Profile on the voive-ports 0/1/0 and 0/1/1 but nothing happend.
11-05-2010 04:33 AM
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?
11-05-2010 06:04 PM
The Trasnlation-rule works as planed.
11-08-2010 04:15 AM
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#
11-08-2010 08:10 AM
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 ?
11-08-2010 10:28 AM
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 .... :-)
11-08-2010 10:41 AM
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
11-09-2010 05:28 AM
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
11-10-2010 09:07 AM
so Problem solved thanks for your anwsers.
rule 1 /^.*/ /xxx/ Type unknown national
..... syntax :-)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide