Re: [asterisk-users] PRI over T1 calls dropping, cause 100
Michelle Dupuis wrote: I have a T1 link from asterisk 1.2.23 (also tried with 1.4.13) to a Meridian Option 61C. Calls either way drop with error Channel 0/23, span 1 got hangup, cause 100. Can anyone offer insight into the cause and solution/workaround? (I tried upgrading to Ast 1.4.13, and upgrading matching zaptel libpri, put the problem is identical). For testing, I tried a call from the Meridian to an extension which just plays the monkey sounds. The call sets up, but I never hear monkeys (just a busy tone) as the call disconnects immediately. I have three attachments below: 1. The CLI output showing a dropped call (inbound from Meridian1) 2. A PRI DEBUG of the same call, showing !! Invalid Protocol Profile field 0x11 in the trace. 3. A PRI INTENSE DEBUG SPAN 1 of the same call. (I tried upgrading to Ast 1.4.13 prior to this call trace - same result) From what I can see in the trace, a Q.932 Interpretation component is not handled. Sowhat do I do? The Q.932 part of that and invalid protocol profile field shouldn't be your problem. It looks like the switch is rejecting it for this reason: Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 1 (reference 23/0x17) (Originator) Message type: RELEASE (77) [08 02 81 e4] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (6) ] Invalid information element contents. You need to figure out what the switch doesn't seem to be liking. Looks like it doesn't like the way one of the IEs is coded. Matthew Fredrickson Thanks, MD =1=== !! Invalid Protocol Profile field 0x11 -- Accepting call from '2004000' to '111' on channel 0/23, span 1 -- Executing NoOp(Zap/23-1, Incoming call from Meridian1) in new stack -- Executing NoOp(Zap/23-1, From number: 2004000| revised to 2004) in new stack -- Executing Set(Zap/23-1, CALLERID(num)=2004) in new stack -- Executing NoOp(Zap/23-1, From name: TELEPHONE ROOM) in new stack -- Executing Macro(Zap/23-1, dialfromMeridian|111) in new stack -- Executing NoOp(Zap/23-1, Incoming call to number 111| which maps to device: ) in new stack -- Executing GotoIf(Zap/23-1, 1?NoMatch) in new stack -- Goto (macro-dialfromMeridian,s,5) -- Executing NoOp(Zap/23-1, Invalid extension in macro dialfromMeridian) in new stack -- Executing Hangup(Zap/23-1, ) in new stack == Spawn extension (macro-dialfromMeridian, s, 6) exited non-zero on 'Zap/23-1' in macro 'dialfromMeridian' == Spawn extension (macro-dialfromMeridian, s, 6) exited non-zero on 'Zap/23-1' -- Hungup 'Zap/23-1' !! Invalid Protocol Profile field 0x11 -- Accepting call from '2004000' to '123' on channel 0/23, span 1 -- Executing Answer(Zap/23-1, ) in new stack -- Executing Playback(Zap/23-1, tt-monkeys) in new stack -- Playing 'tt-monkeys' (language 'en') -- Channel 0/23, span 1 got hangup, cause 100 == Spawn extension (entryocgexternal, 123, 2) exited non-zero on 'Zap/23-1' -- Hungup 'Zap/23-1' =2=== *CLI pri debug span 1 Enabled debugging on span 1 Protocol Discriminator: Q.931 (8) len=61 Call Ref: len= 1 (reference 23/0x17) (Originator) Message type: SETUP (5) [04 03 80 90 a2] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: u-Law (34) [18 04 e9 80 83 17] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 DS1 Identifier: 0 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 0 Channel: 23 ] [1c 0a 11 be a1 06 02 01 01 02 01 01] Facility (len=12, codeset=0) [ 0x11, 0xbe, 0xa1, 0x06, 0x02, 0x01, 0x01, 0x02, 0x01, 0x01 ] [28 0f b1 54 45 4c 45 50 48 4f 4e 45 20 52 4f 4f 4d] Display (len=15) Charset: 31 [ TELEPHONE ROOM ] [6c 09 09 80 32 30 30 34 30 30 30] Calling Number (len=11) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '2004000' ] [70 04 89 31 32 33] Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) '123' ] -- Making new call for cr 23 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 28 (cs0, Facility) !! Invalid Protocol Profile field 0x11 -- Processing IE 40 (cs0, Display) -- Processing IE 108 (cs0,
Re: [asterisk-users] PRI over T1 calls dropping, cause 100
Matt ( All), Thanks for the info below. You obviously responded to my bug report too (thanks again) - so I'll keep my dialog on the list to benefit other users too. From your response below and on the bug site, I'm starting to get the picture. I know the firmware on the Nortel is old, so I'm guessing that libpri is sending something that the Nortel does not know how to handle. Is there a way to dumb down what libpri sends? From everything I've read PRI is an evolving standard - and older devices may struggle with newer extensions/developments. (This might be very handy for users trying to talk to old pbx's.) Is there a workaround? Thanks, Michelle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Fredrickson Sent: Thursday, November 01, 2007 1:06 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] PRI over T1 calls dropping, cause 100 Michelle Dupuis wrote: I have a T1 link from asterisk 1.2.23 (also tried with 1.4.13) to a Meridian Option 61C. Calls either way drop with error Channel 0/23, span 1 got hangup, cause 100. Can anyone offer insight into the cause and solution/workaround? (I tried upgrading to Ast 1.4.13, and upgrading matching zaptel libpri, put the problem is identical). For testing, I tried a call from the Meridian to an extension which just plays the monkey sounds. The call sets up, but I never hear monkeys (just a busy tone) as the call disconnects immediately. I have three attachments below: 1. The CLI output showing a dropped call (inbound from Meridian1) 2. A PRI DEBUG of the same call, showing !! Invalid Protocol Profile field 0x11 in the trace. 3. A PRI INTENSE DEBUG SPAN 1 of the same call. (I tried upgrading to Ast 1.4.13 prior to this call trace - same result) From what I can see in the trace, a Q.932 Interpretation component is not handled. Sowhat do I do? The Q.932 part of that and invalid protocol profile field shouldn't be your problem. It looks like the switch is rejecting it for this reason: Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 1 (reference 23/0x17) (Originator) Message type: RELEASE (77) [08 02 81 e4] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (6) ] Invalid information element contents. You need to figure out what the switch doesn't seem to be liking. Looks like it doesn't like the way one of the IEs is coded. Matthew Fredrickson Thanks, MD =1=== !! Invalid Protocol Profile field 0x11 -- Accepting call from '2004000' to '111' on channel 0/23, span 1 -- Executing NoOp(Zap/23-1, Incoming call from Meridian1) in new stack -- Executing NoOp(Zap/23-1, From number: 2004000| revised to 2004) in new stack -- Executing Set(Zap/23-1, CALLERID(num)=2004) in new stack -- Executing NoOp(Zap/23-1, From name: TELEPHONE ROOM) in new stack -- Executing Macro(Zap/23-1, dialfromMeridian|111) in new stack -- Executing NoOp(Zap/23-1, Incoming call to number 111| which maps to device: ) in new stack -- Executing GotoIf(Zap/23-1, 1?NoMatch) in new stack -- Goto (macro-dialfromMeridian,s,5) -- Executing NoOp(Zap/23-1, Invalid extension in macro dialfromMeridian) in new stack -- Executing Hangup(Zap/23-1, ) in new stack == Spawn extension (macro-dialfromMeridian, s, 6) exited non-zero on 'Zap/23-1' in macro 'dialfromMeridian' == Spawn extension (macro-dialfromMeridian, s, 6) exited non-zero on 'Zap/23-1' -- Hungup 'Zap/23-1' !! Invalid Protocol Profile field 0x11 -- Accepting call from '2004000' to '123' on channel 0/23, span 1 -- Executing Answer(Zap/23-1, ) in new stack -- Executing Playback(Zap/23-1, tt-monkeys) in new stack -- Playing 'tt-monkeys' (language 'en') -- Channel 0/23, span 1 got hangup, cause 100 == Spawn extension (entryocgexternal, 123, 2) exited non-zero on 'Zap/23-1' -- Hungup 'Zap/23-1' =2=== *CLI pri debug span 1 Enabled debugging on span 1 Protocol Discriminator: Q.931 (8) len=61 Call Ref: len= 1 (reference 23/0x17) (Originator) Message type: SETUP (5) [04 03 80 90 a2] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: u-Law (34) [18 04 e9 80 83 17] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel
Re: [asterisk-users] PRI over T1 calls dropping, cause 100
The T1 was setup as tie line, not a trunk. The Bell guy tried setting up the line 2 ways: 1. As a trunk. This did not work because: a) When he typed in the access code for the trunk on a phone set (and then any numbers), the call never appeared on the Asterisk side. b) The Bell guy said that unless Asterisk was generating a dialtone, a trunk would not work. (I struggled to understand these explanations...but figured I must be missing something) 2. As a tie line. This sort of worked because a) When he typed the access code for the tie line on a phone set, he got a second dial tone. b) When he dialed any digits thereafter, the call was handed across the T1 and I saw it on the asterisk side. Can you give me any specifics (or a link) on how the Meridian side should be configured? Thanks, MD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andres Sent: Tuesday, October 30, 2007 11:50 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] PRI over T1 calls dropping, cause 100 -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 28 (cs0, Facility) Handle Q.932 ROSE Invoke component -- Processing IE 108 (cs0, Calling Party Number) The Meridian is trying to Invoke the Remote Operations Service Element (ROSE). That is used to support interactive applications. My guess is that Meridian thinks its talking to another Meridian and its trying to startup some application. That is not going to play well with Asterisk. You need to see how to disable that, or configure a plain trunk without any fancy stuff at the Meridian side. Andres. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI over T1 calls dropping, cause 100
On 10/31/07, Michelle Dupuis [EMAIL PROTECTED] wrote: The T1 was setup as tie line, not a trunk. The Bell guy tried setting up the line 2 ways: 1. As a trunk. This did not work because: a) When he typed in the access code for the trunk on a phone set (and then any numbers), the call never appeared on the Asterisk side. b) The Bell guy said that unless Asterisk was generating a dialtone, a trunk would not work (I struggled to understand these explanations...but figured I must be missing something) There is no dialtone on a PRI/T1. I think what he meant was you need to change in your zaptel config pri_cpe to be pri_net then it will allow you to setup that trunk. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] PRI over T1 calls dropping, cause 100
I have a T1 link from asterisk 1.2.23 (also tried with 1.4.13) to a Meridian Option 61C. Calls either way drop with error Channel 0/23, span 1 got hangup, cause 100. Can anyone offer insight into the cause and solution/workaround? (I tried upgrading to Ast 1.4.13, and upgrading matching zaptel libpri, put the problem is identical). For testing, I tried a call from the Meridian to an extension which just plays the monkey sounds. The call sets up, but I never hear monkeys (just a busy tone) as the call disconnects immediately. I have three attachments below: 1. The CLI output showing a dropped call (inbound from Meridian1) 2. A PRI DEBUG of the same call, showing !! Invalid Protocol Profile field 0x11 in the trace. 3. A PRI INTENSE DEBUG SPAN 1 of the same call. (I tried upgrading to Ast 1.4.13 prior to this call trace - same result) From what I can see in the trace, a Q.932 Interpretation component is not handled. Sowhat do I do? Thanks, MD =1=== !! Invalid Protocol Profile field 0x11 -- Accepting call from '2004000' to '111' on channel 0/23, span 1 -- Executing NoOp(Zap/23-1, Incoming call from Meridian1) in new stack -- Executing NoOp(Zap/23-1, From number: 2004000| revised to 2004) in new stack -- Executing Set(Zap/23-1, CALLERID(num)=2004) in new stack -- Executing NoOp(Zap/23-1, From name: TELEPHONE ROOM) in new stack -- Executing Macro(Zap/23-1, dialfromMeridian|111) in new stack -- Executing NoOp(Zap/23-1, Incoming call to number 111| which maps to device: ) in new stack -- Executing GotoIf(Zap/23-1, 1?NoMatch) in new stack -- Goto (macro-dialfromMeridian,s,5) -- Executing NoOp(Zap/23-1, Invalid extension in macro dialfromMeridian) in new stack -- Executing Hangup(Zap/23-1, ) in new stack == Spawn extension (macro-dialfromMeridian, s, 6) exited non-zero on 'Zap/23-1' in macro 'dialfromMeridian' == Spawn extension (macro-dialfromMeridian, s, 6) exited non-zero on 'Zap/23-1' -- Hungup 'Zap/23-1' !! Invalid Protocol Profile field 0x11 -- Accepting call from '2004000' to '123' on channel 0/23, span 1 -- Executing Answer(Zap/23-1, ) in new stack -- Executing Playback(Zap/23-1, tt-monkeys) in new stack -- Playing 'tt-monkeys' (language 'en') -- Channel 0/23, span 1 got hangup, cause 100 == Spawn extension (entryocgexternal, 123, 2) exited non-zero on 'Zap/23-1' -- Hungup 'Zap/23-1' =2=== *CLI pri debug span 1 Enabled debugging on span 1 Protocol Discriminator: Q.931 (8) len=61 Call Ref: len= 1 (reference 23/0x17) (Originator) Message type: SETUP (5) [04 03 80 90 a2] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: u-Law (34) [18 04 e9 80 83 17] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 DS1 Identifier: 0 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 0 Channel: 23 ] [1c 0a 11 be a1 06 02 01 01 02 01 01] Facility (len=12, codeset=0) [ 0x11, 0xbe, 0xa1, 0x06, 0x02, 0x01, 0x01, 0x02, 0x01, 0x01 ] [28 0f b1 54 45 4c 45 50 48 4f 4e 45 20 52 4f 4f 4d] Display (len=15) Charset: 31 [ TELEPHONE ROOM ] [6c 09 09 80 32 30 30 34 30 30 30] Calling Number (len=11) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '2004000' ] [70 04 89 31 32 33] Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) '123' ] -- Making new call for cr 23 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- Processing IE 28 (cs0, Facility) !! Invalid Protocol Profile field 0x11 -- Processing IE 40 (cs0, Display) -- Processing IE 108 (cs0, Calling Party Number) -- Processing IE 112 (cs0, Called Party Number) Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 23/0x17) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 97] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 23 ] -- Accepting call from '2004000' to '123' on channel 0/23, span 1 -- Executing Answer(Zap/23-1, ) in new stack Protocol Discriminator: Q.931 (8) len=10 Call Ref: len= 2 (reference 23/0x17) (Terminator) Message type: CONNECT (7) [18 03 a9 83 97] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
Re: [asterisk-users] PRI over T1 calls dropping, cause 100
-- Processing IE 24 (cs0, Channel Identification) -- Processing IE 28 (cs0, Facility) Handle Q.932 ROSE Invoke component -- Processing IE 108 (cs0, Calling Party Number) The Meridian is trying to Invoke the Remote Operations Service Element (ROSE). That is used to support interactive applications. My guess is that Meridian thinks its talking to another Meridian and its trying to startup some application. That is not going to play well with Asterisk. You need to see how to disable that, or configure a plain trunk without any fancy stuff at the Meridian side. Andres. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
