Problem with ISDN redirecting number on CME

Unanswered Question
May 14th, 2012
User Badges:

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'

                Plan:ISDN, Type:International

        Called Party Number i = 0xC1, '10zz'

                Plan:ISDN, Type:Subscriber(local)

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

direct-inward-dial


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'

                Plan:ISDN, Type:International

         Called Party Number i = 0xC1, '1000'                  <- note it shows the FIRST number of the DID block

                Plan:ISDN, Type:Subscriber(local)

        Redirecting Number i = '!', 0x008F, '1238888'        <- note it also shows prefix whereas with called party prefix is chopped

                Plan:ISDN, Type:National

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
paolo bevilacqua Mon, 05/14/2012 - 12:36
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

j-broomfield Mon, 05/14/2012 - 12:41
User Badges:

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"

acampbell Mon, 05/14/2012 - 17:13
User Badges:
  • Green, 3000 points or more

John


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
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml#con5


!
!
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
!
!
voice-port 0/0/0:15
translation-profile incoming REDIRECTED
!
!




Regards,
Alex.
Please rate useful posts.

j-broomfield Mon, 05/14/2012 - 18:17
User Badges:

Hi Alex,

     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.


John.

Dennis Mink Mon, 05/14/2012 - 18:59
User Badges:
  • Blue, 1500 points or more

John,


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.


R.,

j-broomfield Tue, 05/15/2012 - 01:59
User Badges:

Hi,

     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


Regards,

John.

schaef350 Tue, 10/28/2014 - 11:37
User Badges:
  • Bronze, 100 points or more

Had you ever resolved this?  I am facing a similar case now.

paolo bevilacqua Mon, 05/14/2012 - 21:21
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

Actions

This Discussion

Related Content