jiangcl
asked on
Cisco AS5300 VOIP & T1 ISDN PRI
If you have good idea, Please e-mail:jiangcl@yahoo.com
Problem Name:
DID(incoming)+Call Forward(outgoing) in the same T1 line in Cisco5300
Problem Description:
I am configuring a Cisco AS5300 device for VOIP. The version of IOS is IOS12.1.5T9.
4 Channelized T1/PRI port(s) and 24 Voice resource(s)
I just want to use DID function to call a PC terminal User(access phone number is his terminal ID,You can just equal this terminal to netmeeting). PSTN interface is only 1 T1 (ISDNPRI from NTT).
PSTN User----->Cisco AS5300----->Gatekeeper(dev
I have successfully configure it.
But when I testing a value-add function, Call forward, I found a problem whn Cisco communicate with NTT Switch about T1 ISDN PRI signal.
When PC Terminal User does not register to gatekeeper or offline and set a forward phone number which gatekeeper know, Gatekeeper will tell caller Cisco AS5300 to call forward-phone number(GK using ACF in H.323 to notice Cisco 5300, ) then This call is sent outgoing using the same T1 line, just like PSTN User(caller)----->Cisco AS5300-----> PSTN User(callee).
OK, I make 3 test.
First, I use DID function(one-time dial, no dialtone again when you access Cisco5300) to finish this call forward procedure..outgoing call receive ?Invalid information element contents? error from NTT switch.Call failed.
Second, I do not use DID function,just dial a phone number to access Cisco5300, then hear dialtone , then dial other phone number to outgoing this call using the same T1 line, It?s succeed.
Third, I do not use DID function,just dial a phone number to access Cisco5300, then hear dialtone , then dial PC terminal User ID,GK found it?s offline, then call forward back to Cisco as5300, using the same T1 line to make a outgoing call. It?s success.
I attach the first test of three tests about debug isdn q931 and debug isdn events log file as following
(1) PSTN----8222222(It?s a access phone number of Cisco T1 ,and also ID of one PC terminal,This terminal user is offline, then forward to Phone1)----- Phone 1 (Service provider is NTT Docomo)
Error occur at
00:14:33: ISDN Se0:23: RX <- STATUS pd = 8 callref = 0x005D
00:14:33: Cause i = 0x82E41E - Invalid information element contents
00:14:33: Call State i = 0x07
result in following dsiconnect result
00:14:33: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x0005
00:14:33: Cause i = 0x80A9 - Temporary failure
Called Party Phone just ring twice.
At first, It seems that when using DID, First access call is still call proceding, and ISDN serial 0:23(D channel) has no time to deal with a outgoing call at the same time.It sound like synchronize problem.
So I prepare for another T1 for outgoing call.That is to say, ISDN Serial 0:23(first T1?s D channel) to deal with incoming call, ISDN Serial 1:23(Second T1?s D channel) to deal with outgoing call.
I have tried it, But also failed.The log file is the same as this one..
LOG FILE of debug isdn q931 and debug isdn events
00:14:27: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x005D
00:14:27: Bearer Capability i = 0x8090A2
00:14:27: Channel ID i = 0xA193040000
00:14:27: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:14:27: Called Party Number i = 0x80, '8222222', Plan:Unknown, Type:Un
known
00:14:27: Low Layer Compat i = 0x8090A2
00:14:27: High Layer Compat i = 0x9181
00:14:27: ISDN Se0:23: Incoming call id = 0x0003, dsl 0
00:14:27: Negotiated CCB->int_id 0 B-chan 0, req->int_id 0, B-chan 19
00:14:27: CCPRI_ReleaseChan CCB->B_Chan zero
00:14:27: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x3 CALL_INCOMING
an5300#
00:14:27: ISDN Se0:23: CALL_INCOMING dsl 0 bchan 18
00:14:27: ISDN Se0:23: CALL_INCOMING: call type is VOICE ULAW, bchan = 18
00:14:27: ISDN Se0:23: llc valid, speed 64, call type is VOICE
speed:0 async:N
00:14:27: ISDN Se0:23: Event: Received a VOICE call from <unknown> on B18 at 64
Kb/s
00:14:28: ISDN Se0:23: process_pri_simple(): msg 74, call id 0x3, bchan 18, call
type VOICE
00:14:28: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x805D
00:14:28: Channel ID i = 0xA993040000
00:14:28: ISDN Se0:23: Outgoing call id = 0x8007, dsl 0
00:14:28: ISDN Se0:23: process_pri_call(): call id 0x8007, number 09085852228, s
peed 1611856088, call type VOICE
00:14:28: ISDN Se0:23: override plan/type, comparing 09085852228/.*, (regexp) (m
atch)
00:14:28: ISDN Se0:23: override plan/type, comparing /.*, (regexp) (match)
00:14:28: ISDN Se0:23: override plan/type, comparing 09085852228/.*, (regexp) (m
atch)
00:14:28: building outgoing channel id for call nfas_int is 0 len is 0
00:14:28: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x0005
00:14:28: Bearer Capability i = 0x8090A2
00:14:28: Channel ID i = 0xA98397
00:14:28: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:14:28: Called Party Number i = 0x80, '09085852228', Plan:Unknown, Typ
e:Unknown
00:14:28: Low Layer Compat i = 0x8090A2
00:14:28: High Layer Compat i = 0x9181
00:14:28: ISDN Se0:23: RX <- CALL_PROC pd = 8 callref = 0x8005
00:14:28: Channel ID i = 0xA98397
00:14:28: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8007 CALL_PROCEEDING
00:14:28: ISDN Se0:23: PRI Event: 0, bchan = 22, call type = VOICE
00:14:28: (Se0:23) TX call proc to appl thru CDAPI,call_id (0x8007)
an5300#
00:14:33: ISDN Se0:23: RX <- ALERTING pd = 8 callref = 0x8005
00:14:33: Progress Ind i = 0x8488 - In-band info or appropriate now avai
lable
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8007 CALL_PROGRESS
00:14:33: ISDN Se0:23: event CALL_PROGRESS dsl 0
00:14:33: ISDN Se0:23: process_pri_simple(): msg 78, call id 0x3, bchan 18, call
type VOICE
00:14:33: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x805D
00:14:33: Progress Ind i = 0x8488 - In-band info or appropriate now avai
lable
00:14:33: ISDN Se0:23: RX <- STATUS pd = 8 callref = 0x005D
00:14:33: Cause i = 0x82E41E - Invalid information element contents
00:14:33: Call State i = 0x07
00:14:33: ISDN Se0:23: TX -> RELEASE pd = 8 callref = 0x805D
00:14:33: Cause i = 0x80E41E - Invalid information element contents
00:14:33: ISDN Se0:23: RX <- RELEASE_COMP pd = 8 callref = 0x005D
00:14:33: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 19, call id 0x3, call type VOI
CE
00:14:33: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 19
00:14:33: CCPRI_ReleaseChan released b_dsl 0 B_Chan 19
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x3 CALL_DISC
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x3 CALL_CLEARED
00:14:33: ISDN Se0:23: received CALL_CLEARED call_id 0x3
00:14:33: ISDN Se0:23: process_disconnect(): call id 0x8007, call type is VOICE,
b_idb 0x61F38C7C, ces 1, cause Temporary failure(0x29)
00:14:33: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x0005
00:14:33: Cause i = 0x80A9 - Temporary failure
00:14:33: ISDN Se0:23: RX <- RELEASE pd = 8 callref = 0x8005
00:14:33: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 23, call id 0x8007, call type
VOICE
00:14:33: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 23
00:14:33: CCPRI_ReleaseChan released b_dsl 0 B_Chan 23
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8007 CALL_CLEARED
00:14:33: ISDN Se0:23: received CALL_CLEARED call_id 0x8007
00:14:33: ISDN Se0:23: TX -> RELEASE_COMP pd = 8 callref = 0x0005
(2) PSTN----8222222(It?s a access phone number of Cisco T1 ,and also ID of one PC terminal,This terminal user is offline, then forward to Phone 2)----- Phone 2(Service provider is KDD)Difference SP?s phone has different ring time.
Error occur at
0:17:01: ISDN Se0:23: Ux_BadMsg(): Invalid Message for call state 9, call id 0x
4, call ref 0x805E, event 0x89
result in following dsiconnect result
00:17:06: ISDN Se0:23: RX <- DISCONNECT pd = 8 callref = 0x005E
00:17:06: Cause i = 0x82E6333130 - Recovery on timer expiry
Called Party Phone just ring six or seven, so if you pick up /accept this call when ringing, It?s a successful call. While NTT Docomo phone1 just ring one or twice, You seldom have chance to pick up/accept call.
LOG FILE of debug isdn q931 and debug isdn events
00:16:55: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x005E
00:16:55: Bearer Capability i = 0x8090A2
00:16:55: Channel ID i = 0xA193040000
00:16:55: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:16:55: Called Party Number i = 0x80, '8222222', Plan:Unknown, Type:Un
known
00:16:55: Low Layer Compat i = 0x8090A2
00:16:55: High Layer Compat i = 0x9181
00:16:55: ISDN Se0:23: Incoming call id = 0x0004, dsl 0
00:16:55: Negotiated CCB->int_id 0 B-chan 0, req->int_id 0, B-chan 19
00:16:55: CCPRI_ReleaseChan CCB->B_Chan zero
00:16:55: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x4 CALL_INCOMING
an5300#
00:16:55: ISDN Se0:23: CALL_INCOMING dsl 0 bchan 18
00:16:55: ISDN Se0:23: CALL_INCOMING: call type is VOICE ULAW, bchan = 18
00:16:55: ISDN Se0:23: llc valid, speed 64, call type is VOICE
speed:0 async:N
00:16:55: ISDN Se0:23: Event: Received a VOICE call from <unknown> on B18 at 64
Kb/s
00:16:56: ISDN Se0:23: process_pri_simple(): msg 74, call id 0x4, bchan 18, call
type VOICE
00:16:56: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x805E
00:16:56: Channel ID i = 0xA993040000
00:16:56: ISDN Se0:23: Outgoing call id = 0x8008, dsl 0
00:16:56: ISDN Se0:23: process_pri_call(): call id 0x8008, number 09012228888, s
peed 1611856088, call type VOICE
00:16:56: ISDN Se0:23: override plan/type, comparing 09012228888/.*, (regexp) (m
atch)
00:16:56: ISDN Se0:23: override plan/type, comparing /.*, (regexp) (match)
00:16:56: ISDN Se0:23: override plan/type, comparing 09012228888/.*, (regexp) (m
atch)
00:16:56: building outgoing channel id for call nfas_int is 0 len is 0
00:16:56: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x0006
00:16:56: Bearer Capability i = 0x8090A2
00:16:56: Channel ID i = 0xA98397
00:16:56: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:16:56: Called Party Number i = 0x80, '09012228888', Plan:Unknown, Typ
e:Unknown
00:16:56: Low Layer Compat i = 0x8090A2
00:16:56: High Layer Compat i = 0x9181
00:16:56: ISDN Se0:23: RX <- CALL_PROC pd = 8 callref = 0x8006
00:16:56: Channel ID i = 0xA98397
00:16:56: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8008 CALL_PROCEEDING
00:16:56: ISDN Se0:23: PRI Event: 0, bchan = 22, call type = VOICE
00:16:56: (Se0:23) TX call proc to appl thru CDAPI,call_id (0x8008)
an5300#
00:17:01: ISDN Se0:23: RX <- PROGRESS pd = 8 callref = 0x8006
00:17:01: Progress Ind i = 0x8488 - In-band info or appropriate now avai
lable
00:17:01: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8008 CALL_PROGRESS
00:17:01: ISDN Se0:23: event CALL_PROGRESS dsl 0
00:17:01: ISDN Se0:23: process_pri_simple(): msg 78, call id 0x4, bchan 18, call
type VOICE
00:17:01: ISDN Se0:23: Ux_BadMsg(): Invalid Message for call state 9, call id 0x
4, call ref 0x805E, event 0x89
an5300#
00:17:06: ISDN Se0:23: RX <- DISCONNECT pd = 8 callref = 0x005E
00:17:06: Cause i = 0x82E6333130 - Recovery on timer expiry
00:17:06: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x4 CALL_DISC
00:17:06: ISDN Se0:23: TX -> RELEASE pd = 8 callref = 0x805E
00:17:06: ISDN Se0:23: process_disconnect(): call id 0x8008, call type is VOICE,
b_idb 0x61F38C7C, ces 1, cause Recovery on timer expiry(0x66)
00:17:06: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x0006
00:17:06: Cause i = 0x80E6 - Recovery on timer expiry
00:17:06: ISDN Se0:23: RX <- RELEASE_COMP pd = 8 callref = 0x005E
00:17:06: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 19, call id 0x4, call type VOI
CE
an5300#
00:17:06: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 19
00:17:06: CCPRI_ReleaseChan released b_dsl 0 B_Chan 19
00:17:06: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x4 CALL_CLEARED
00:17:06: ISDN Se0:23: received CALL_CLEARED call_id 0x4
00:17:06: ISDN Se0:23: RX <- RELEASE pd = 8 callref = 0x8006
00:17:06: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 23, call id 0x8008, call type
VOICE
00:17:06: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 23
00:17:06: CCPRI_ReleaseChan released b_dsl 0 B_Chan 23
00:17:06: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8008 CALL_CLEARED
00:17:06: ISDN Se0:23: received CALL_CLEARED call_id 0x8008
00:17:06: ISDN Se0:23: TX -> RELEASE_COMP pd = 8 callref = 0x0006
This Cisco AS5300's related configuration:
controller T1 0
framing esf
clock source line primary
linecode b8zs
pri-group timeslots 1-24
!
controller T1 1
framing esf
clock source line secondary 1
linecode b8zs
!
!
interface Ethernet0
ip address x.x.x.x 255.255.255.0
no cdp enable
h323-gateway voip interface
h323-gateway voip id GK ipaddr x.x.x.x 1719
h323-gateway voip h323-id test
!
interface Serial0:23
no ip address
ip mroute-cache
isdn switch-type primary-ntt
isdn incoming-voice modem
isdn map address .* plan unknown type unknown
no cdp enable
!
interface Serial1:23
no ip address
ip mroute-cache
isdn switch-type primary-ntt
isdn incoming-voice modem
isdn map address .* plan unknown type unknown
no cdp enable
!
voice-port 0:D
cptone JP
bearer-cap Speech
!
voice-port 1:D
cptone JP
bearer-cap Speech
!
dial-peer voice 1 pots
destination-pattern 813
port 0:D
prefix 03
!
dial-peer voice 2 pots
destination-pattern 8190
port 0:D
prefix 090
!
dial-peer voice 3 voip
destination-pattern 8T
session target ras
codec g723r63
no vad
!
dial-peer voice 4 pots
incoming called-number 8T
direct-inward-dial
port 0:D
!
gateway
I think It must be Cisco IOS Bug with NTT or other Japan switch related T1 ISDN PRI.
Please give me some suggestion.
Wish your reply ASAP.
Thanks.
Problem Name:
DID(incoming)+Call Forward(outgoing) in the same T1 line in Cisco5300
Problem Description:
I am configuring a Cisco AS5300 device for VOIP. The version of IOS is IOS12.1.5T9.
4 Channelized T1/PRI port(s) and 24 Voice resource(s)
I just want to use DID function to call a PC terminal User(access phone number is his terminal ID,You can just equal this terminal to netmeeting). PSTN interface is only 1 T1 (ISDNPRI from NTT).
PSTN User----->Cisco AS5300----->Gatekeeper(dev
I have successfully configure it.
But when I testing a value-add function, Call forward, I found a problem whn Cisco communicate with NTT Switch about T1 ISDN PRI signal.
When PC Terminal User does not register to gatekeeper or offline and set a forward phone number which gatekeeper know, Gatekeeper will tell caller Cisco AS5300 to call forward-phone number(GK using ACF in H.323 to notice Cisco 5300, ) then This call is sent outgoing using the same T1 line, just like PSTN User(caller)----->Cisco AS5300-----> PSTN User(callee).
OK, I make 3 test.
First, I use DID function(one-time dial, no dialtone again when you access Cisco5300) to finish this call forward procedure..outgoing call receive ?Invalid information element contents? error from NTT switch.Call failed.
Second, I do not use DID function,just dial a phone number to access Cisco5300, then hear dialtone , then dial other phone number to outgoing this call using the same T1 line, It?s succeed.
Third, I do not use DID function,just dial a phone number to access Cisco5300, then hear dialtone , then dial PC terminal User ID,GK found it?s offline, then call forward back to Cisco as5300, using the same T1 line to make a outgoing call. It?s success.
I attach the first test of three tests about debug isdn q931 and debug isdn events log file as following
(1) PSTN----8222222(It?s a access phone number of Cisco T1 ,and also ID of one PC terminal,This terminal user is offline, then forward to Phone1)----- Phone 1 (Service provider is NTT Docomo)
Error occur at
00:14:33: ISDN Se0:23: RX <- STATUS pd = 8 callref = 0x005D
00:14:33: Cause i = 0x82E41E - Invalid information element contents
00:14:33: Call State i = 0x07
result in following dsiconnect result
00:14:33: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x0005
00:14:33: Cause i = 0x80A9 - Temporary failure
Called Party Phone just ring twice.
At first, It seems that when using DID, First access call is still call proceding, and ISDN serial 0:23(D channel) has no time to deal with a outgoing call at the same time.It sound like synchronize problem.
So I prepare for another T1 for outgoing call.That is to say, ISDN Serial 0:23(first T1?s D channel) to deal with incoming call, ISDN Serial 1:23(Second T1?s D channel) to deal with outgoing call.
I have tried it, But also failed.The log file is the same as this one..
LOG FILE of debug isdn q931 and debug isdn events
00:14:27: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x005D
00:14:27: Bearer Capability i = 0x8090A2
00:14:27: Channel ID i = 0xA193040000
00:14:27: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:14:27: Called Party Number i = 0x80, '8222222', Plan:Unknown, Type:Un
known
00:14:27: Low Layer Compat i = 0x8090A2
00:14:27: High Layer Compat i = 0x9181
00:14:27: ISDN Se0:23: Incoming call id = 0x0003, dsl 0
00:14:27: Negotiated CCB->int_id 0 B-chan 0, req->int_id 0, B-chan 19
00:14:27: CCPRI_ReleaseChan CCB->B_Chan zero
00:14:27: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x3 CALL_INCOMING
an5300#
00:14:27: ISDN Se0:23: CALL_INCOMING dsl 0 bchan 18
00:14:27: ISDN Se0:23: CALL_INCOMING: call type is VOICE ULAW, bchan = 18
00:14:27: ISDN Se0:23: llc valid, speed 64, call type is VOICE
speed:0 async:N
00:14:27: ISDN Se0:23: Event: Received a VOICE call from <unknown> on B18 at 64
Kb/s
00:14:28: ISDN Se0:23: process_pri_simple(): msg 74, call id 0x3, bchan 18, call
type VOICE
00:14:28: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x805D
00:14:28: Channel ID i = 0xA993040000
00:14:28: ISDN Se0:23: Outgoing call id = 0x8007, dsl 0
00:14:28: ISDN Se0:23: process_pri_call(): call id 0x8007, number 09085852228, s
peed 1611856088, call type VOICE
00:14:28: ISDN Se0:23: override plan/type, comparing 09085852228/.*, (regexp) (m
atch)
00:14:28: ISDN Se0:23: override plan/type, comparing /.*, (regexp) (match)
00:14:28: ISDN Se0:23: override plan/type, comparing 09085852228/.*, (regexp) (m
atch)
00:14:28: building outgoing channel id for call nfas_int is 0 len is 0
00:14:28: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x0005
00:14:28: Bearer Capability i = 0x8090A2
00:14:28: Channel ID i = 0xA98397
00:14:28: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:14:28: Called Party Number i = 0x80, '09085852228', Plan:Unknown, Typ
e:Unknown
00:14:28: Low Layer Compat i = 0x8090A2
00:14:28: High Layer Compat i = 0x9181
00:14:28: ISDN Se0:23: RX <- CALL_PROC pd = 8 callref = 0x8005
00:14:28: Channel ID i = 0xA98397
00:14:28: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8007 CALL_PROCEEDING
00:14:28: ISDN Se0:23: PRI Event: 0, bchan = 22, call type = VOICE
00:14:28: (Se0:23) TX call proc to appl thru CDAPI,call_id (0x8007)
an5300#
00:14:33: ISDN Se0:23: RX <- ALERTING pd = 8 callref = 0x8005
00:14:33: Progress Ind i = 0x8488 - In-band info or appropriate now avai
lable
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8007 CALL_PROGRESS
00:14:33: ISDN Se0:23: event CALL_PROGRESS dsl 0
00:14:33: ISDN Se0:23: process_pri_simple(): msg 78, call id 0x3, bchan 18, call
type VOICE
00:14:33: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x805D
00:14:33: Progress Ind i = 0x8488 - In-band info or appropriate now avai
lable
00:14:33: ISDN Se0:23: RX <- STATUS pd = 8 callref = 0x005D
00:14:33: Cause i = 0x82E41E - Invalid information element contents
00:14:33: Call State i = 0x07
00:14:33: ISDN Se0:23: TX -> RELEASE pd = 8 callref = 0x805D
00:14:33: Cause i = 0x80E41E - Invalid information element contents
00:14:33: ISDN Se0:23: RX <- RELEASE_COMP pd = 8 callref = 0x005D
00:14:33: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 19, call id 0x3, call type VOI
CE
00:14:33: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 19
00:14:33: CCPRI_ReleaseChan released b_dsl 0 B_Chan 19
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x3 CALL_DISC
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x3 CALL_CLEARED
00:14:33: ISDN Se0:23: received CALL_CLEARED call_id 0x3
00:14:33: ISDN Se0:23: process_disconnect(): call id 0x8007, call type is VOICE,
b_idb 0x61F38C7C, ces 1, cause Temporary failure(0x29)
00:14:33: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x0005
00:14:33: Cause i = 0x80A9 - Temporary failure
00:14:33: ISDN Se0:23: RX <- RELEASE pd = 8 callref = 0x8005
00:14:33: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 23, call id 0x8007, call type
VOICE
00:14:33: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 23
00:14:33: CCPRI_ReleaseChan released b_dsl 0 B_Chan 23
00:14:33: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8007 CALL_CLEARED
00:14:33: ISDN Se0:23: received CALL_CLEARED call_id 0x8007
00:14:33: ISDN Se0:23: TX -> RELEASE_COMP pd = 8 callref = 0x0005
(2) PSTN----8222222(It?s a access phone number of Cisco T1 ,and also ID of one PC terminal,This terminal user is offline, then forward to Phone 2)----- Phone 2(Service provider is KDD)Difference SP?s phone has different ring time.
Error occur at
0:17:01: ISDN Se0:23: Ux_BadMsg(): Invalid Message for call state 9, call id 0x
4, call ref 0x805E, event 0x89
result in following dsiconnect result
00:17:06: ISDN Se0:23: RX <- DISCONNECT pd = 8 callref = 0x005E
00:17:06: Cause i = 0x82E6333130 - Recovery on timer expiry
Called Party Phone just ring six or seven, so if you pick up /accept this call when ringing, It?s a successful call. While NTT Docomo phone1 just ring one or twice, You seldom have chance to pick up/accept call.
LOG FILE of debug isdn q931 and debug isdn events
00:16:55: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x005E
00:16:55: Bearer Capability i = 0x8090A2
00:16:55: Channel ID i = 0xA193040000
00:16:55: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:16:55: Called Party Number i = 0x80, '8222222', Plan:Unknown, Type:Un
known
00:16:55: Low Layer Compat i = 0x8090A2
00:16:55: High Layer Compat i = 0x9181
00:16:55: ISDN Se0:23: Incoming call id = 0x0004, dsl 0
00:16:55: Negotiated CCB->int_id 0 B-chan 0, req->int_id 0, B-chan 19
00:16:55: CCPRI_ReleaseChan CCB->B_Chan zero
00:16:55: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x4 CALL_INCOMING
an5300#
00:16:55: ISDN Se0:23: CALL_INCOMING dsl 0 bchan 18
00:16:55: ISDN Se0:23: CALL_INCOMING: call type is VOICE ULAW, bchan = 18
00:16:55: ISDN Se0:23: llc valid, speed 64, call type is VOICE
speed:0 async:N
00:16:55: ISDN Se0:23: Event: Received a VOICE call from <unknown> on B18 at 64
Kb/s
00:16:56: ISDN Se0:23: process_pri_simple(): msg 74, call id 0x4, bchan 18, call
type VOICE
00:16:56: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x805E
00:16:56: Channel ID i = 0xA993040000
00:16:56: ISDN Se0:23: Outgoing call id = 0x8008, dsl 0
00:16:56: ISDN Se0:23: process_pri_call(): call id 0x8008, number 09012228888, s
peed 1611856088, call type VOICE
00:16:56: ISDN Se0:23: override plan/type, comparing 09012228888/.*, (regexp) (m
atch)
00:16:56: ISDN Se0:23: override plan/type, comparing /.*, (regexp) (match)
00:16:56: ISDN Se0:23: override plan/type, comparing 09012228888/.*, (regexp) (m
atch)
00:16:56: building outgoing channel id for call nfas_int is 0 len is 0
00:16:56: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x0006
00:16:56: Bearer Capability i = 0x8090A2
00:16:56: Channel ID i = 0xA98397
00:16:56: Calling Party Number i = 0x00A3, Plan:Unknown, Type:Unknown
00:16:56: Called Party Number i = 0x80, '09012228888', Plan:Unknown, Typ
e:Unknown
00:16:56: Low Layer Compat i = 0x8090A2
00:16:56: High Layer Compat i = 0x9181
00:16:56: ISDN Se0:23: RX <- CALL_PROC pd = 8 callref = 0x8006
00:16:56: Channel ID i = 0xA98397
00:16:56: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8008 CALL_PROCEEDING
00:16:56: ISDN Se0:23: PRI Event: 0, bchan = 22, call type = VOICE
00:16:56: (Se0:23) TX call proc to appl thru CDAPI,call_id (0x8008)
an5300#
00:17:01: ISDN Se0:23: RX <- PROGRESS pd = 8 callref = 0x8006
00:17:01: Progress Ind i = 0x8488 - In-band info or appropriate now avai
lable
00:17:01: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8008 CALL_PROGRESS
00:17:01: ISDN Se0:23: event CALL_PROGRESS dsl 0
00:17:01: ISDN Se0:23: process_pri_simple(): msg 78, call id 0x4, bchan 18, call
type VOICE
00:17:01: ISDN Se0:23: Ux_BadMsg(): Invalid Message for call state 9, call id 0x
4, call ref 0x805E, event 0x89
an5300#
00:17:06: ISDN Se0:23: RX <- DISCONNECT pd = 8 callref = 0x005E
00:17:06: Cause i = 0x82E6333130 - Recovery on timer expiry
00:17:06: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x4 CALL_DISC
00:17:06: ISDN Se0:23: TX -> RELEASE pd = 8 callref = 0x805E
00:17:06: ISDN Se0:23: process_disconnect(): call id 0x8008, call type is VOICE,
b_idb 0x61F38C7C, ces 1, cause Recovery on timer expiry(0x66)
00:17:06: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x0006
00:17:06: Cause i = 0x80E6 - Recovery on timer expiry
00:17:06: ISDN Se0:23: RX <- RELEASE_COMP pd = 8 callref = 0x005E
00:17:06: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 19, call id 0x4, call type VOI
CE
an5300#
00:17:06: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 19
00:17:06: CCPRI_ReleaseChan released b_dsl 0 B_Chan 19
00:17:06: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x4 CALL_CLEARED
00:17:06: ISDN Se0:23: received CALL_CLEARED call_id 0x4
00:17:06: ISDN Se0:23: RX <- RELEASE pd = 8 callref = 0x8006
00:17:06: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 23, call id 0x8008, call type
VOICE
00:17:06: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 23
00:17:06: CCPRI_ReleaseChan released b_dsl 0 B_Chan 23
00:17:06: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x8008 CALL_CLEARED
00:17:06: ISDN Se0:23: received CALL_CLEARED call_id 0x8008
00:17:06: ISDN Se0:23: TX -> RELEASE_COMP pd = 8 callref = 0x0006
This Cisco AS5300's related configuration:
controller T1 0
framing esf
clock source line primary
linecode b8zs
pri-group timeslots 1-24
!
controller T1 1
framing esf
clock source line secondary 1
linecode b8zs
!
!
interface Ethernet0
ip address x.x.x.x 255.255.255.0
no cdp enable
h323-gateway voip interface
h323-gateway voip id GK ipaddr x.x.x.x 1719
h323-gateway voip h323-id test
!
interface Serial0:23
no ip address
ip mroute-cache
isdn switch-type primary-ntt
isdn incoming-voice modem
isdn map address .* plan unknown type unknown
no cdp enable
!
interface Serial1:23
no ip address
ip mroute-cache
isdn switch-type primary-ntt
isdn incoming-voice modem
isdn map address .* plan unknown type unknown
no cdp enable
!
voice-port 0:D
cptone JP
bearer-cap Speech
!
voice-port 1:D
cptone JP
bearer-cap Speech
!
dial-peer voice 1 pots
destination-pattern 813
port 0:D
prefix 03
!
dial-peer voice 2 pots
destination-pattern 8190
port 0:D
prefix 090
!
dial-peer voice 3 voip
destination-pattern 8T
session target ras
codec g723r63
no vad
!
dial-peer voice 4 pots
incoming called-number 8T
direct-inward-dial
port 0:D
!
gateway
I think It must be Cisco IOS Bug with NTT or other Japan switch related T1 ISDN PRI.
Please give me some suggestion.
Wish your reply ASAP.
Thanks.
Also under int e0:
h323-gateway voip bind srcaddr x.x.x.x
h323-gateway voip bind srcaddr x.x.x.x
ASKER
I am configuring a Cisco AS5300 device for VOIP. The version of IOS
is IOS12.1.5T9.
4 Channelized T1/PRI port(s) and 24 Voice resource(s)
I just want to use DID function to call a PC terminal User(access
phone number is his terminal ID,You can just equal this terminal to
netmeeting). PSTN interface is only 1 T1 (ISDNPRI from NTT).
PSTN User----->Cisco AS5300----->Gatekeeper(dev
own)----PC terminal User
I have successfully configure it.
But when I testing a value-add function, Call forward, I found a
problem whn Cisco communicate with NTT Switch about T1 ISDN PRI
signal.
When PC Terminal User does not register to gatekeeper or offline and
set a forward phone number which gatekeeper know, Gatekeeper will tell
caller Cisco AS5300 to call forward-phone number(GK using ACF in H.323
to notice Cisco 5300, ) then This call is sent outgoing using the same
T1 line, just like PSTN User(caller)----->Cisco AS5300-----> PSTN
User(callee).
First, I use DID function(one-time dial, no dialtone again when
you access Cisco5300) to finish this call forward procedure..outgoing
call receive “Invalid information element contents” error
from NTT switch.Call failed.
> >
> > I have confirm this problem with NTT, They told me that Cisco
> > AS5300 just forward alerting message to Calling NTT Switch received
> > from called NTT switch(in this case,It’s the same switch).
> > And to Calling NTT Switch, This alerting message’s original
> > should be Cisco as5300, a TE device,
> > But the Alerting message received from called NTT switch’s
> > ’s original s is CO,just Called NTT Switch.
> > So Cisco AS5300 do not change this field , then It cause NTT Switch
> > Invalid information element contents error.
> > Just like following(incoming call is channel 18,Outgoing call is
> > channel 22).
> > So does it mean that Cisco as5300 does not support ISDN signal relay
> > or forward?If Cisco devices do not change the related field,It can
> > not be supportted.
> > Or there is some internal command to change this field,
> > Or I use the wrong version(Cisco IOS IP PLUS 12.1.5T9)
> > I have report it to Cisco as a IOS bug .
> > any suggestion to me? How to solve this problem?
> >
> > Best Regards.
> > J.C.L
> > 7/24/2001
> >
> > Following is a test I made,just use a dial-peer to DID incoming call,
> > another dial-peer to send out outgoing call.
> > It is failed also, just the reason mentioned above.
> >
> > related configuration
> > dial-peer voice 4 pots
> > incoming called-number 8T
> > direct-inward-dial
> > port 0:D
> > !
> > !
> > dial-peer voice 6 pots
> > destination-pattern 8271945
> > port 0:D
> > prefix 09085850228
> >
> > THIS is debug isdn q931 and debug isdn events
> > 19:01:31: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x0072
> > 19:01:31: Bearer Capability i = 0x8090A2
> > 19:01:31: Channel ID i = 0xA193040000
> > 19:01:31: Calling Party Number i = 0x00A3, Plan:Unknown,
> > Type:Unknown
> > 19:01:31: Called Party Number i = 0x80, '8271945',
> > Plan:Unknown, Type:Un
> > known
> > 19:01:31: Low Layer Compat i = 0x8090A2
> > 19:01:31: High Layer Compat i = 0x9181
> > 19:01:31: ISDN Se0:23: Incoming call id = 0x0018, dsl 0
> > 19:01:31: Negotiated CCB->int_id 0 B-chan 0, req->int_id 0, B-chan 19
> > 19:01:31: CCPRI_ReleaseChan CCB->B_Chan zero
> > 19:01:31: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x18 CALL_INCOMING
> > an5300#
> > 19:01:31: ISDN Se0:23: CALL_INCOMING dsl 0 bchan 18
> > 19:01:31: ISDN Se0:23: CALL_INCOMING: call type is VOICE ULAW, bchan =
> > 18
> > 19:01:31: ISDN Se0:23: llc valid, speed 64, call type is VOICE
> > speed:0 async:N
> > 19:01:31: ISDN Se0:23: Event: Received a VOICE call from <unknown> on
> > B18 at 64
> > Kb/s
> > 19:01:31: ISDN Se0:23: process_pri_simple(): msg 74, call id 0x18,
> > bchan 18, cal
> > l type VOICE
> > 19:01:31: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x8072
> > 19:01:31: Channel ID i = 0xA993040000
> > 19:01:32: ISDN Se0:23: Outgoing call id = 0x801E, dsl 0
> > 19:01:32: ISDN Se0:23: process_pri_call(): call id 0x801E, number
> > 09085850228, s
> > peed 1611856088, call type VOICE
> > 19:01:32: ISDN Se0:23: override plan/type, comparing 09085850228/.*,
> > (regexp) (m
> > atch)
> > 19:01:32: ISDN Se0:23: override plan/type, comparing /.*, (regexp)
> > (match)
> > 19:01:32: ISDN Se0:23: override plan/type, comparing 09085850228/.*,
> > (regexp) (m
> > atch)
> > 19:01:32: building outgoing channel id for call nfas_int is 0 len is
> > 0
> > 19:01:32: ISDN Se0:23: TX -> SETUP pd = 8 callref = 0x001C
> > 19:01:32: Sending Complete
> > 19:01:32: Bearer Capability i = 0x8090A2
> > 19:01:32: Channel ID i = 0xA98397
> > 19:01:32: Calling Party Number i = 0x00A3, Plan:Unknown,
> > Type:Unknown
> > 19:01:32: Called Party Number i = 0x80, '09085850228',
> > Plan:Unknown, Typ
> > e:Unknown
> > 19:01:32: Low Layer Compat i = 0x8090A2
> > 19:01:32: High Layer Compat i = 0x9181
> > 19:01:32: ISDN Se0:23: RX <- CALL_PROC pd = 8 callref = 0x801C
> > 19:01:32: Channel ID i = 0xA98397
> > 19:01:32: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x801E CALL_PROCEEDING
> > 19:01:32: ISDN Se0:23: PRI Event: 0, bchan = 22, call type = VOICE
> > 19:01:32: (Se0:23) TX call proc to appl thru CDAPI,call_id (0x801E)
> >
> > an5300#
> > 19:01:37: ISDN Se0:23: RX <- ALERTING pd = 8 callref = 0x801C
> > 19:01:37: Progress Ind i = 0x8488 - In-band info or
> > appropriate now avai
> > lable
> > 19:01:37: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x801E CALL_PROGRESS
> > 19:01:37: ISDN Se0:23: event CALL_PROGRESS dsl 0
> > 19:01:37: ISDN Se0:23: process_pri_simple(): msg 78, call id 0x18,
> > bchan 18, cal
> > l type VOICE
> > 19:01:37: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x8072
> > 19:01:37: Progress Ind i = 0x8488 - In-band info or
> > appropriate now avai
> > lable
> > 19:01:37: ISDN Se0:23: RX <- STATUS pd = 8 callref = 0x0072
> > 19:01:37: Cause i = 0x82E41E - Invalid information element
> > contents
> > 19:01:37: Call State i = 0x07
> > 19:01:37: ISDN Se0:23: TX -> RELEASE pd = 8 callref = 0x8072
> > 19:01:37: Cause i = 0x80E41E - Invalid information element
> > contents
> > 19:01:37: ISDN Se0:23: RX <- RELEASE_COMP pd = 8 callref = 0x0072
> > 19:01:37: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 19, call id 0x18,
> > call type VO
> > ICE
> > 19:01:37: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 19
> > 19:01:37: CCPRI_ReleaseChan released b_dsl 0 B_Chan 19
> > 19:01:37: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x18 CALL_DISC
> > 19:01:37: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x18 CALL_CLEARED
> > 19:01:37: ISDN Se0:23: received CALL_CLEARED call_id 0x18
> > 19:01:37: ISDN Se0:23: process_disconnect(): call id 0x801E, call type
> > is VOICE,
> > b_idb 0x61F38C7C, ces 1, cause Unknown cause value(0x0)
> > 19:01:37: ISDN Se0:23: TX -> DISCONNECT pd = 8 callref = 0x001C
> > 19:01:37: Cause i = 0x8080 - Unknown cause value
> > 19:01:37: ISDN Se0:23: RX <- RELEASE pd = 8 callref = 0x801C
> > 19:01:37: ISDN Se0:23: CCPRI_ReleaseCall(): bchan 23, call id 0x801E,
> > call type
> > VOICE
> > 19:01:37: CC_CHAN_ReleaseChanpri for DSL 0 B-chan 23
> > 19:01:37: CCPRI_ReleaseChan released b_dsl 0 B_Chan 23
> > 19:01:37: ISDN Se0:23: LIF_EVENT: ces/callid 1/0x801E CALL_CLEARED
> > 19:01:37: ISDN Se0:23: received CALL_CLEARED call_id 0x801E
> > 19:01:37: ISDN Se0:23: TX -> RELEASE_COMP pd = 8 callref = 0x001C
> > an5300#
Again...what version of vfcWARE??
ASKER
vcware 7.2.3
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This question appears to be abandoned. I will allow one week before I close this question
with the following recommendation:
- points to crieman
if there is any objection to this recommendation then please post it here within 7 days.
thanks,
lrmoore@nw
EE Cleanup Volunteer
per recommendation
SpideyMod
Community Support Moderator @Experts Exchange
SpideyMod
Community Support Moderator @Experts Exchange
How many digits are you outpulsing? What exactly is the number being dialed? I see "Called Party Number i = 0x80, '09085850228'" . If it's national call, you've got too many digits there. If it's INTERnational, not enough digits. I'd say that's an invalid info element. Isn't that the cause code?
You said you set it up for the second D channel to deal with the outbound call. This second D channel is just a standalone or a backup to a primary? You can't do what you're trying to do independently of the othe D channel IF it's a backup - I saw NFAS mentioned in call setup message. there are 2 type of nfas. the first would be d & D backup, the second would be D and 23+ B's 1 D channel, control serverl T-1's). Is this an NFAS arrangement w/ D & D backup? If it is, check the interface numbers. The T-1 with the Primary D should be interface=0, the one with the backup should be interface 1. If this is your arrangement, the backup is MATED to the primary and sits in standby state in casue the primary goes out of service. If you're trying to make this call from this type of arrangement it won't work. If each T-1 is a "standalone" (no mated pair) then each interface will always=0. The protocol is showing "build outgoing call for nfas_int=0." If this is the 2nd D channel and if its a standalone, then it's supposed to be interface zero. If it's a backup D, it's interface 1 and it CANNOT be in an active in service state at the same time as the primary and/or operating independently from it. They go together like husband and wife. One goes to work, the other stays home & cooks.
Also, it looks like the call set up message has codeset 6 information elements in it. And when you get an error message stating "Invalid information element contents", there's a problem in the call setup message. Codest 6 is sometimes the culprit. Sometimes the inband info isn't coded correctly...Certain telecom trunks pass this info through transparently even when the call isn't being set up as end-to-end ISDN which it doesn't look like it is .The Calling Number TYPE/PLAN would be specified as NATIONAL ISDN, and the Called Number TYPE/PLAN would also be specified as NATIONAL ISDN. If it's not an end to end isdn call if it's going froma T-1 to a POTS line, it's passing through a local carriers network to get where it's going. I'm spoiled and don't have to decode any hex on my protocol analyzer at work. The display is 100% ENglish and it's color-coded. I haven't decoded hex in years so I can't see everything in this protocol.
You said you set it up for the second D channel to deal with the outbound call. This second D channel is just a standalone or a backup to a primary? You can't do what you're trying to do independently of the othe D channel IF it's a backup - I saw NFAS mentioned in call setup message. there are 2 type of nfas. the first would be d & D backup, the second would be D and 23+ B's 1 D channel, control serverl T-1's). Is this an NFAS arrangement w/ D & D backup? If it is, check the interface numbers. The T-1 with the Primary D should be interface=0, the one with the backup should be interface 1. If this is your arrangement, the backup is MATED to the primary and sits in standby state in casue the primary goes out of service. If you're trying to make this call from this type of arrangement it won't work. If each T-1 is a "standalone" (no mated pair) then each interface will always=0. The protocol is showing "build outgoing call for nfas_int=0." If this is the 2nd D channel and if its a standalone, then it's supposed to be interface zero. If it's a backup D, it's interface 1 and it CANNOT be in an active in service state at the same time as the primary and/or operating independently from it. They go together like husband and wife. One goes to work, the other stays home & cooks.
Also, it looks like the call set up message has codeset 6 information elements in it. And when you get an error message stating "Invalid information element contents", there's a problem in the call setup message. Codest 6 is sometimes the culprit. Sometimes the inband info isn't coded correctly...Certain telecom trunks pass this info through transparently even when the call isn't being set up as end-to-end ISDN which it doesn't look like it is .The Calling Number TYPE/PLAN would be specified as NATIONAL ISDN, and the Called Number TYPE/PLAN would also be specified as NATIONAL ISDN. If it's not an end to end isdn call if it's going froma T-1 to a POTS line, it's passing through a local carriers network to get where it's going. I'm spoiled and don't have to decode any hex on my protocol analyzer at work. The display is 100% ENglish and it's color-coded. I haven't decoded hex in years so I can't see everything in this protocol.
What version of VcWare is on the vfc?
The IOS and Vcware versions must match according to:http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/iosrn/vcwrn/vcwrmtrx.htm
try debugging the call using debug h225 asn1--just do one call this is a massive debug.
Also, The pri-group is not configured under T1 1