We have just been assigned a new PRI to which the telco has redirected two old numbers (fax and main switchboard) from a previous office.
For sake of the discussion, range of DID's on new PRI is 1231000-1231099 (100 numbers), old fax is 1238888, old switchboard is 1239999
When dialling from the outside world any of the DID's, debug q931 shows a simple
Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band info
Calling Party Number i = 0x1183, 'xxxxxxxx'
Called Party Number i = 0xC1, '10zz'
where xxxxxxx is the calling party ID , zz is whatever the caller dialed, and I can match that with a dial-peer using:
incoming called-number 10zz
However, when someone from the outside world dials one of the old numbers, the debug I get is:
Progress Ind i = 0x8283 - Origination address is non-ISDN
Calling Party Number i = 0x1183, 'xxxxxxxxxx'
Called Party Number i = 0xC1, '1000' <- note it shows the FIRST number of the DID block
Redirecting Number i = '!', 0x008F, '1238888' <- note it also shows prefix whereas with called party prefix is chopped
but the problem is that I can't match the redirecting number in a dial-peer, so I have no way to split the 1238888 to a fax port and the 1239999 to a human attendant. It keeps matching dial-peers based on the called party 1000
I can see the difference in the calls in the q931 debug on that "redirecting number", but I don't know how to act on it.
Does anyone have a suggestion for this?
Switch type is configured as primary-net5, this is with Telefonica and it's in Peru.
thanks in advance.
You cannot easily match on redirecting number.
You must ask telco that the send the called number as called number, not redirecting number, for both old a new range of DIDs.
They may say they can't, int that case just insist.
You say cannot EASILY match... Any diffcult way no matter how convoluted? (maybe with some sort of tcl script or something?)
As you can guess, getting the telco to change that is a daunting task... "no, we can't do that" = "we don't understand what you are talking about"
Can you try fixing this with your own FAX & SWBD numbers and VOICE-PORT and give it a test.
According to this link you can match on REDIRECTED number
Voice translation-rule 100
rule 1 /1238888$/ /MY FAX DN/
rule 2 /1239999$/ /MY SWBD DN/
Voice translation-rule 200
rule 1 // //
voice translation-profile REDIRECTED
translate redirect-called 100
translate called 200
translation-profile incoming REDIRECTED
Please rate useful posts.
Thanks for the try, but no biscuit...
Yes, what you indicate DOES succesfully match and translate the "redirecting number" field, and you can change it around as you want, however, after the change, the "called party" field remains the same, and the dial-peers continue to match in the same manner, ie they cannot discern between the two different types of calls.
Your example translation-rule 100 *does* affect the redirecting number field. Unfortunately that's all it does, and I continue to have no way of differentiating the calls based on that field.
What I'd need (somehow) would be to check the redirecting number field, and then (based on rules) paste that number into the called party field as that *would* then allow me to choose dial-peers.
I'm getting to the point where I think that I can't do it from IOS, however as the fields are there, it may be possible to do this with a TCL script. Unfortunately that is beyond my competence level.
I have done similar cutovers dozens of time, not sure about your Location, but here in Australia, you can port old numbers to a new Circuit (PRI). This would mean in your case that the "old fax" would be ported onto the new Circuit and would show up as called number. This is absolutely different from a provider doing a redirect. I this something that you have asked your provider to do? Cos If they can that you would only need a dial peer covering the old number, without doing any redirect manipulation.
Obviously if the numbers could be ported, just simply addding them as additional DID's to the circuit, then the problem would be over.
Unfortunately, on the one hand number portability is not always automatically available and on the other (as I'm sure you've all found before) the telco's are not always helpful or knowledgeable about what they can or can't do.
In this case, the new office location is served by a different telco central office than the old one, thus compounding the problem.
In short: porting the numbers is not available
Yes, you would need a custom TCL/IVR script to route by redirecting number. You can contact me privately if you really want to go that route.