Restricted ISDN-channel to new DID block

Unanswered Question
Jan 15th, 2007
User Badges:

I have two isdn-30 lines with call manager & one voice gateway 3725 router (1mfte1 & 2mfte1 e1 interfaces). They are currently supporting one did block 6828710 to 6828-7699. I am installing second new did block 6829 - 3000 to 6829-3199. PTT have make arrangement on new did block will be coming at the last 10 channels to the second isdn line. Can Cisco IOS controls/sets ISDN signal coming from the first 20 lines is for existing did block 68287xxx and last 10 lines is for new did block 6829xxx

below is my current voice pot definition

dial-peer voice 2003 voip


preference 2

destination-pattern 68293...

progress_ind setup enable 3

translate-outgoing called 2

voice-class h323 1

session target ipv4:

dtmf-relay h245-alphanumeric

codec g711ulaw

fax rate disable

fax protocol cisco

no vad


comments from PTT

The reason you are seeing 6828 7333 is because the call is going through

tp1.01 jpg1348 uam1-01 or it is going through the first 20 channels of

tp1.02 jpg1348 uam1-01. If you configure the calls to go through the

last 10 channels of tp1.02 jpg1348 uam1-01 then it will show you the


As for the incoming call you should also configure to receive call from

the last 10 channels of tp1.02 jpg1348 uam1-01.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
paolo bevilacqua Mon, 01/15/2007 - 18:39
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hello auraycats,

The switch will decide on which channel to send the incoming call, and the router will give the call to the CM no matter the channel used. Since the blocks do not overlap, there is no problem anyway.

I do not quite understand why your telco got so worried in making sure that one DID block is sent into one line/set and the other into another. E.G. what happens after the 'last 10 channels' of that circuit are taken, and the 11th call comes in ??

auraycats Mon, 01/15/2007 - 21:07
User Badges:

I did not indicated my problem.

For outgoing call, isdn trace tells me the call is from new did block ie. 6829 3133. However, the called party displays the prime number 6829 7333 as the caller.

For incoming call, isdn trace tells me the call is going to 6829 3133 but the 3133 extension did not ring. PTT explained they allocated the last 10 pri lines to new block. If the voice traffic takes/comes in using the first 20 lines, called party will show prime number as well as no incoming call.

paolo bevilacqua Tue, 01/16/2007 - 03:23
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hi auraycats,

For outgoing calls, the router strictly uses the first available channel in either ascending or descending order, depending on how is configured. It is not supported to have 'channel sets' and select an arbitrary channel for outgoing calls, at least with H.323. Perhaps that would be possible with MGCP, but I doubt. I'm surprised to know that telco has provisioned the line based on the assumption that your equipment will use a specific channel depending on DID.

For incoming calls, I cannot tell you why the phone doesn't ring. Once the call comes in, and you said it does, it only depends on your dial-peer and CM configuration to route appropriately, so may you need to do a little more debug.

auraycats Tue, 01/16/2007 - 06:28
User Badges:

tks p.bevilacqua.

I will review the Cisco design with ptt and will ask what solution/suggestion he can offer to me. my bottom line is to mizemize the in-house Cisco equipment and avoid increasing additional recurring cost on adding new isdn-pri line.

paolo bevilacqua Tue, 01/16/2007 - 07:26
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hi again,

from what I've seen in my experience, telco should provision both PRI's in hunt group, so that for outgoing calls, as long the calling number falls within your DID blocks, it will be passed to the called party. Any other number will be replaced with the pilot number. You can always configure the CM so that certain extensions will present the main number and not their DID.

For incoming, you should be able to accept any number on any PRI.

This setup has the advantage that in the event one PRI goes out ot service, the functionality is unchanged, albeit with a reduced number of channels.

Of course, if your call volume does not require two PRIs, you should ask to have one only.

auraycats Tue, 01/16/2007 - 22:38
User Badges:

I filed my debug isdn q931 for incoming call to new did block 68293133 from 68287433(my extension) & dial peers in the router. the error showed

Jan 17 14:21:52.161 SG: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x9DAE

Cause i = 0x829C - Invalid number format (incomplete number)

Progress Ind i = 0x8288 - In-band info or appropriate now available

Jan 17 14:21:52.165 SG: ISDN Se1/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x9A32

I hope it can help why the call did not go to call mgr and ring the phone. May be my new dial peer is wrong. Your guidance.

paolo bevilacqua Wed, 01/17/2007 - 04:16
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hello auraycats,

I had a little trouble reading your debug because is truncated.

However, seems that the router is sending the disconnect on the incoming call. We would need to see the output from debug cch323 (either all or session) to see if the call is going to the CM, and with which numbers. I'm not familiar with the CM but at least can tell if the problem is there, or not.

paolo bevilacqua Thu, 01/18/2007 - 06:55
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hi auraycats,

The CM is disconnecting the call:


Jan 18 08:03:17.544 SG: generic_send_setup:raw message is 219 bytes:04 03 80 90 A3 18 03 A9 83 9A 6C 0A 01 81 36 38 32 38 37 34 33 33 70 09 C1 36 38 32 39 33 31 33 33 A1 1C B7 9E 01 00 03 67 74 64 00 00 00 AC 49 41 4D 2C 0D 0A 50 52 4E 2C 69 73 64 6E 2A 2C 2C 4E 45 54 35 2A 2C 0D 0A 55 53 49 2C 72 61 74 65 2C 63 2C 73 2C 63 2C 31 0D 0A 55 53 49 2C 6C 61 79 31 2C 61 6C 61 77 0D 0A 54 4D 52 2C 30 30 0D 0A 43 50 4E 2C 30 32 2C 2C 31 2C 36 38 32 39 33 31 33 33 0D 0A 43 47 4E 2C 30 30 2C 2C 31 2C 79 2C 32 2C 36 38 32 38 37 34 33 33 0D 0A 43 50 43 2C 30 39 0D 0A 46 43 49 2C 2C 2C 2C 2C 2C 2C 79 2C 0D 0A 47 43 49 2C 32 32 34 63 36 63 36 38 61 35 62 65 31 31 64 62 62 65 35 64 39 33 31 32 39 39 62 64 36 34 66 31 0D 0A 0D 0A


Jan 18 08:03:17.544 SG: src address = of h225SetupRequest

Jan 18 08:03:17.544 SG: dest address = of h225SetupRequest

Jan 18 08:03:17.544 SG: H.225 SM: changing from H225_IDLE state to H225_REQ_FS_SETUP state for callID A1338

Jan 18 08:03:17.544 SG: cch323_ct_main: SOCK 13 Event 0x1

Jan 18 08:03:17.556 SG: cch323_ct_main: SOCK 13 Event 0x1

Jan 18 08:03:17.556 SG: [1]towner_data=0x63703818, len=45, msgPtr=0x6439F158

cch323_gw_process_read_socket: received msg for H.225


Jan 18 08:03:17.556 SG: cch323_h225_receiver: received msg of type RELEASEIND_CHOSEN

Jan 18 08:03:17.556 SG: release_ind: disconnect cause 1 location code 0

Jan 18 08:03:17.556 SG: h323_set_release_source_for_peer: ownCallId[660280], src[4]

If you absolutely need to translate the called number before passing to the CM (but I think that is not necessary) please use the voice translation-profile. Else just configure the CM appropriately (I can't help in this)

You can see statistics of succesful/failed calls on the router, with

show h323 gateway [cause-code stats]

auraycats Fri, 01/19/2007 - 00:23
User Badges:

I will escalate my problem to PTT and Cisco TAC. I will post the solution after I fix the problem. Tks your effort.


This Discussion