From: Alexander Arsenyev (GU/ETL) (alexander.arsenyev@ericsson.com)
Date: Sat Apr 17 2004 - 16:39:34 GMT-3
Hello Tim,
See my answers inline.
HTH,
Cheers
Alex
-----Original Message-----
From: Tim Last [mailto:packtmon@yahoo.com]
Sent: 15 April 2004 21:45
To: Alexander Arsenyev (GU/ETL)
Subject: RE: Voice Translation Rule Challenge
Hey Alex,
Major, major, thank you. I've been trying for a while to understand this without too much success. If you don't mind, can I ask you a couple follow up questions.
1) When there are multiple rules (or entries), does each rule work independently from all the others? In other words, when digits are dialed and multiple translations rules exist, does the rtr just look for the 1st applicable rule, execute it and stop looking for other rules?
[Alexander Arsenyev (GU/ETL)] I believe yes.
Or, is it possible for a single input string, multiple rules will be executed?
[Alexander Arsenyev (GU/ETL)] I can't make it to work in my tests...
2) Is the reason rule 1 wasn't used because the input was 45678 and rule 1 will only go into effect if the 1st 3 dialed digits are 555?
[Alexander Arsenyev (GU/ETL)] Yes
3) Do the keywords potentially change how the rule works? How?
[Alexander Arsenyev (GU/ETL)] Good question! AFAIK, keywords such as "international" etc. either translate input numbering type
unconditionally or leave it intact (if no keyword is specified).
In other words, "rule" subcommand has 3 parameters: input called number/string to match (can be UNIX-style regexp), string to substitute
(cannot be a regexp) and output numbering type (cannot be matched against input called number' numbering type but can be skipped -
I guess in order to preserve input called number' numbering type).
4) Of the different keywords that can be added, should I know any of them and what they do as it relates to how the translation works? Or, would you say, in your best judgement, all the keywords are really beyond the scope of the R&S lab (which, BTW, would quite please me) and I can safely ignore them?
[Alexander Arsenyev (GU/ETL)] Sort of - to the extent of using numbering type for dial-peer matching and number translation.
AFAIK, there are no way of specifying numbering type in "csim start" command
and if You configure dial-peer with any numbering type other than "unknown" if won't route the call
when "csim start" is used (haven't tried it with FXS port, though). It appears that "numbering type" is checked
AFTER usual dial-peer matching and if dial-peer numbering type does not match the called number' numbering type
then call is dropped and no other attempts to match dial-peer are made. See my test below:
dial-peer voice 100 voip
numbering-type unknown
destination-pattern 999+
session target ipv4:172.17.2.2
!
dial-peer voice 101 voip
numbering-type national
destination-pattern ^999$
session target ipv4:172.17.2.2
Dial-peer 101 is best match for called number 999 and dial-peer 100 is second best match. When I do "csim start 999"
I get following:
r6#csim start 999
csim: called number = 999, loop count = 1 ping count = 0
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0
r6#
*Mar 1 05:46:57.165: Inside dpMatchCore:
*Mar 1 05:46:57.165: destination pattn: 999 expanded string: 999
*Mar 1 05:46:57.165: MatchNextPeer: Peer 100 matched
*Mar 1 05:46:57.165: MatchNextPeer: Peer 101 matched
r6#
*Mar 1 05:46:57.165: %CALL_CONTROL-6-NUMBERING_TYPE_NO_MATCH: The called number
numbering type did not matchThe event for the callid 101 is being discarded.
As You see the call is being discarded.
I can imagine this could be used in the lab as a way to restrict calls after dial-peer matching if You are
not allowed/prohibited to configure translation rules ;-). Not something I would expect to be in every CCIE lab variant
but You never know what exactly bites You...
Thanks a great deal.
[Alexander Arsenyev (GU/ETL)] No problem, my pleasure.
Tim
"Alexander Arsenyev (GU/ETL)" <alexander.arsenyev@ericsson.com> wrote:
Hello Tim,
I've tested similar translation-rule example from Cisco Doc CD
( http://127.0.0.1:8080/cc/td/doc/product/software/ios122/122cgcr/fvvfax_r/vrf_t.htm#xtocid40 )
on my 2600 router (IOS 12.2(15)T11) and it produced results which are perfectly
inline with UNIX regexp rules but contradict DocCD example. See below:
r6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
r6(config)#translation-rule 21
r6(config-translate)#
r6(config-translate)#Rule 1 555.% 1408555 subscriber international
r6(config-translate)#
r6(config-translate)# Rule 2 8.% 1408555 abbreviated international
r6(config-translate)#^Z
r6#test translation-rule 21 45678 abbreviated
The replaced number: 45671408555; numbering type: international
r6#
As You can see the patttern 8 gets replaced with 1408555 which is expected.
The exampl! es from DocCD and CCO below must be wrong.
Regarding Your second question - the numbering type is called "type of number" in
ITU-T spec Q.931 "ISDN user-network interface layer 3 specification for basic call control".
You can possibly get this spec from www.itu.int .
In short, it's a 3-bit field in Q.931 Information Elements/IEs (like "Called Party Number", etc)
and can have following values:
Bits
7 6 5
0 0 0 Unknown
0 0 1 International number
0 1 0 National number
0 1 1 Network specific number
1 0 0 Subscriber number
1 1 0 Abbreviated number
1 1 1 Reserved for extension
All other values are reserved.
ITU-T spec H.225.0 says that Q.931 messages shall be used for "call setup, call control, and communications
between terminals, gateways, gatekeepers, and MCUs".
HTH,
Cheers
Alex
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Tim Last
S! ent: 12 April 2004 20:41
To: Group Study
Subject: Voice Translation Rule Challenge
Hi,
For those who are interetsed, the example below can be found in the
command reference at
The following shows output for the test translation-rule command:
Router# translation-rule 21
Rule 1 527.% 1408527 subscriber international
Rule 2 8.% 1408527 abbreviated international
Router# test translation-rule 21 45678 abbreviated
Router#
*Jan 19 16:39:14.578:The replace number 45614085278
Router#
*******************
I've looked at the above example for quite a while and don't
understand at all how the 2 rules lead to the result being shown.
Apparently, the 2 rules work together rather than
independently, but could someone explain what's going on?
Also, what does the "abbreviated" keyword do? And, more generally,
where can I find the meanings of the other possible keywords that can be
added to the end of the rule?
Also, can someone confirm that the "21" in the translation
rule is just an arbitrary tag and doesn't have anything to do
with the order in which the rules below it are applied, right?
Thanks in advance, Tim
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:49 GMT-3