RE: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81
Anthony, We had tried using 5ESS, but instead of seeing 4-digit extensions on the Asterisk box we would see the entire 10-digit caller-id value (I assume because Nortel sees it as an external T1). I will try a setup using NI2 on both sides. But if you could provide some more specifics (both for Asterisk and Nortel) it would be greatly appreciated. Thanks, Greg -Original Message- From: Anthony Rodgers [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 6:14 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81 Hi Greg, Our experience is that both Asterisk and Nortel are capable of understanding DMS100 enough to each be able to connect to a real DMS100 - however neither is capable of actually being a DMS100. We actually ended up using 2 PRIs between our Nortel 11C and Asterisk - the first is set up as a tie trunk in the Nortel and uses NI2 on the Asterisk side. This setup allows us to receive caller ID information from the Nortel and is used only for calls from the Nortel to Asterisk. The second PRI is set up as a 5ESS trunk so that the Nortel will accept caller ID from Asterisk and is used only for calls from Asterisk to the Nortel. If you need more specific details, let me know. Regards, -- Anthony Rodgers Business Systems Analyst District of North Vancouver Web: http://www.dnv.org RSS Feed: http://www.dnv.org/rss.asp On Mar 22, 2006, at 3:21 PM, Greg Camp wrote: Hello all, I have Asterisk 1.2.1 and a TE110P connected to a Nortel Meridian Option 81C system. The PRI line is currently setup as DMS100. Here are the relevant lines from zaptel.conf and zapata.conf: zaptel.conf: span=1,1,0,esf,b8zs bchan=1-23 dchan=24 loadzone = us defaultzone = us zapata.conf: [channels] language=en context=from-internal musiconhold=default switchtype=dms100 resetinterval=72000 signalling=pri_net channel=1-23 The Asterisk box will see the call setup message, but according to the d-channel trace (below) a RELEASE(77) message happens shortly after the CALL PROCEEDING(2) message. The effect is that calls between the two systems do not happen. Can someone versed in d-channel messages determine what is going on here? Also, is there any way to tell the Zaptel card to emulate a particular release version for DMS100? I believe the Meridian is expecting Release 36, or something like that (we've tried leaving Release ID blank on the Meridian side with the same results). Protocol Discriminator: Q.931 (8) len=42 Call Ref: len= 1 (reference 20/0x14) (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 14] 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: 20 ] [28 0a b1 47 52 45 47 20 43 41 4d 50] Display (len=10) Charset: 31 [ GREG CAMP ] [6c 06 09 80 34 32 32 34] Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '4224' ] [70 05 e9 34 39 39 31] Called Number (len= 7) [ Ext: 1 TON: Abbreviated number (6) NPI: Private Numbering Plan (9) '4991' ] -- Making new call for cr 20 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- 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 20/0x14) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 94] 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: 20 ] -- Accepting call from '4224' to '4991' on channel 0/20, span 1 Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 1 (reference 20/0x14) (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: Unknown (100), class = Protocol Error (6) ] -- Processing IE 8 (cs0, Cause) -- Channel 0/20
Re: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81
Hi Greg, I'll dig it out - we only expand the outgoing callerID to 10 digits for external (PSTN) calls, so we don't have the CID issues you mention. Regards, -- Anthony Rodgers Business Systems Analyst District of North Vancouver Web: http://www.dnv.org RSS Feed: http://www.dnv.org/rss.asp On Mar 23, 2006, at 6:21 AM, Greg Camp wrote: Anthony, We had tried using 5ESS, but instead of seeing 4-digit extensions on the Asterisk box we would see the entire 10-digit caller-id value (I assume because Nortel sees it as an external T1). I will try a setup using NI2 on both sides. But if you could provide some more specifics (both for Asterisk and Nortel) it would be greatly appreciated. Thanks, Greg -Original Message- From: Anthony Rodgers [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 6:14 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81 Hi Greg, Our experience is that both Asterisk and Nortel are capable of understanding DMS100 enough to each be able to connect to a real DMS100 - however neither is capable of actually being a DMS100. We actually ended up using 2 PRIs between our Nortel 11C and Asterisk - the first is set up as a tie trunk in the Nortel and uses NI2 on the Asterisk side. This setup allows us to receive caller ID information from the Nortel and is used only for calls from the Nortel to Asterisk. The second PRI is set up as a 5ESS trunk so that the Nortel will accept caller ID from Asterisk and is used only for calls from Asterisk to the Nortel. If you need more specific details, let me know. Regards, -- Anthony Rodgers Business Systems Analyst District of North Vancouver Web: http://www.dnv.org RSS Feed: http://www.dnv.org/rss.asp On Mar 22, 2006, at 3:21 PM, Greg Camp wrote: Hello all, I have Asterisk 1.2.1 and a TE110P connected to a Nortel Meridian Option 81C system. The PRI line is currently setup as DMS100. Here are the relevant lines from zaptel.conf and zapata.conf: zaptel.conf: span=1,1,0,esf,b8zs bchan=1-23 dchan=24 loadzone = us defaultzone = us zapata.conf: [channels] language=en context=from-internal musiconhold=default switchtype=dms100 resetinterval=72000 signalling=pri_net channel=1-23 The Asterisk box will see the call setup message, but according to the d-channel trace (below) a RELEASE(77) message happens shortly after the CALL PROCEEDING(2) message. The effect is that calls between the two systems do not happen. Can someone versed in d-channel messages determine what is going on here? Also, is there any way to tell the Zaptel card to emulate a particular release version for DMS100? I believe the Meridian is expecting Release 36, or something like that (we've tried leaving Release ID blank on the Meridian side with the same results). Protocol Discriminator: Q.931 (8) len=42 Call Ref: len= 1 (reference 20/0x14) (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 14] 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: 20 ] [28 0a b1 47 52 45 47 20 43 41 4d 50] Display (len=10) Charset: 31 [ GREG CAMP ] [6c 06 09 80 34 32 32 34] Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '4224' ] [70 05 e9 34 39 39 31] Called Number (len= 7) [ Ext: 1 TON: Abbreviated number (6) NPI: Private Numbering Plan (9) '4991' ] -- Making new call for cr 20 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- 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 20/0x14) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 94] 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: 20 ] -- Accepting call from '4224' to '4991' on channel 0/20, span 1 Protocol Discriminator: Q.931 (8
RE: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81
Anthony, We're trying to add a TIE NI2 line on the Nortel side, but it is asking us about an Integrated Service Access route. We have never setup anything like that. Can you offer some pointers? If this is getting too off-topic (i.e. more Nortel than Asterisk) please feel free to contact me off-list. Thanks, Greg -Original Message- From: Anthony Rodgers [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 10:56 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81 Hi Greg, I'll dig it out - we only expand the outgoing callerID to 10 digits for external (PSTN) calls, so we don't have the CID issues you mention. Regards, -- Anthony Rodgers Business Systems Analyst District of North Vancouver Web: http://www.dnv.org RSS Feed: http://www.dnv.org/rss.asp On Mar 23, 2006, at 6:21 AM, Greg Camp wrote: Anthony, We had tried using 5ESS, but instead of seeing 4-digit extensions on the Asterisk box we would see the entire 10-digit caller-id value (I assume because Nortel sees it as an external T1). I will try a setup using NI2 on both sides. But if you could provide some more specifics (both for Asterisk and Nortel) it would be greatly appreciated. Thanks, Greg -Original Message- From: Anthony Rodgers [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 6:14 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81 Hi Greg, Our experience is that both Asterisk and Nortel are capable of understanding DMS100 enough to each be able to connect to a real DMS100 - however neither is capable of actually being a DMS100. We actually ended up using 2 PRIs between our Nortel 11C and Asterisk - the first is set up as a tie trunk in the Nortel and uses NI2 on the Asterisk side. This setup allows us to receive caller ID information from the Nortel and is used only for calls from the Nortel to Asterisk. The second PRI is set up as a 5ESS trunk so that the Nortel will accept caller ID from Asterisk and is used only for calls from Asterisk to the Nortel. If you need more specific details, let me know. Regards, -- Anthony Rodgers Business Systems Analyst District of North Vancouver Web: http://www.dnv.org RSS Feed: http://www.dnv.org/rss.asp On Mar 22, 2006, at 3:21 PM, Greg Camp wrote: Hello all, I have Asterisk 1.2.1 and a TE110P connected to a Nortel Meridian Option 81C system. The PRI line is currently setup as DMS100. Here are the relevant lines from zaptel.conf and zapata.conf: zaptel.conf: span=1,1,0,esf,b8zs bchan=1-23 dchan=24 loadzone = us defaultzone = us zapata.conf: [channels] language=en context=from-internal musiconhold=default switchtype=dms100 resetinterval=72000 signalling=pri_net channel=1-23 The Asterisk box will see the call setup message, but according to the d-channel trace (below) a RELEASE(77) message happens shortly after the CALL PROCEEDING(2) message. The effect is that calls between the two systems do not happen. Can someone versed in d-channel messages determine what is going on here? Also, is there any way to tell the Zaptel card to emulate a particular release version for DMS100? I believe the Meridian is expecting Release 36, or something like that (we've tried leaving Release ID blank on the Meridian side with the same results). Protocol Discriminator: Q.931 (8) len=42 Call Ref: len= 1 (reference 20/0x14) (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 14] 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: 20 ] [28 0a b1 47 52 45 47 20 43 41 4d 50] Display (len=10) Charset: 31 [ GREG CAMP ] [6c 06 09 80 34 32 32 34] Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '4224' ] [70 05 e9 34 39 39 31] Called Number (len= 7) [ Ext: 1 TON: Abbreviated number (6) NPI: Private Numbering Plan (9) '4991' ] -- Making new call
[Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81
Hello all, I have Asterisk 1.2.1 and a TE110P connected to a Nortel Meridian Option 81C system. The PRI line is currently setup as DMS100. Here are the relevant lines from zaptel.conf and zapata.conf: zaptel.conf: span=1,1,0,esf,b8zs bchan=1-23 dchan=24 loadzone= us defaultzone = us zapata.conf: [channels] language=en context=from-internal musiconhold=default switchtype=dms100 resetinterval=72000 signalling=pri_net channel=1-23 The Asterisk box will see the call setup message, but according to the d-channel trace (below) a RELEASE(77) message happens shortly after the CALL PROCEEDING(2) message. The effect is that calls between the two systems do not happen. Can someone versed in d-channel messages determine what is going on here? Also, is there any way to tell the Zaptel card to emulate a particular release version for DMS100? I believe the Meridian is expecting Release 36, or something like that (we've tried leaving Release ID blank on the Meridian side with the same results). Protocol Discriminator: Q.931 (8) len=42 Call Ref: len= 1 (reference 20/0x14) (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 14] 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: 20 ] [28 0a b1 47 52 45 47 20 43 41 4d 50] Display (len=10) Charset: 31 [ GREG CAMP ] [6c 06 09 80 34 32 32 34] Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '4224' ] [70 05 e9 34 39 39 31] Called Number (len= 7) [ Ext: 1 TON: Abbreviated number (6) NPI: Private Numbering Plan (9) '4991' ] -- Making new call for cr 20 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- 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 20/0x14) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 94] 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: 20 ] -- Accepting call from '4224' to '4991' on channel 0/20, span 1 Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 1 (reference 20/0x14) (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: Unknown (100), class = Protocol Error (6) ] -- Processing IE 8 (cs0, Cause) -- Channel 0/20, span 1 got hangup -- Executing Macro(Zap/20-1, exten-vm|novm|4991) in new stack -- Executing Macro(Zap/20-1, user-callerid) in new stack -- Executing DBget(Zap/20-1, AMPUSER=DEVICE/4224/user) in new stack -- DBget: varname=AMPUSER, family=DEVICE, key=4224/user -- DBget: Value not found in database. -- Executing Macro(Zap/20-1, hangupcall) in new stack -- Executing ResetCDR(Zap/20-1, w) in new stack -- Executing NoCDR(Zap/20-1, ) in new stack -- Executing Wait(Zap/20-1, 5) in new stack == Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'Zap/20-1' in macro 'hangupcall' == Spawn extension (from-internal, h, 1) exited non-zero on 'Zap/20-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request Protocol Discriminator: Q.931 (8) len=9 Call Ref: len= 2 (reference 20/0x14) (Terminator) Message type: RELEASE COMPLETE (90) [08 02 81 90] Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) Ext: 1 Cause: Unknown (16), class = Normal Event (1) ] NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null -- Hungup 'Zap/20-1' Thanks, Greg [EMAIL PROTECTED] Excell Services ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] PRI DMS100 - Nortel Meridian Option 81
Hi Greg, Our experience is that both Asterisk and Nortel are capable of understanding DMS100 enough to each be able to connect to a real DMS100 - however neither is capable of actually being a DMS100. We actually ended up using 2 PRIs between our Nortel 11C and Asterisk - the first is set up as a tie trunk in the Nortel and uses NI2 on the Asterisk side. This setup allows us to receive caller ID information from the Nortel and is used only for calls from the Nortel to Asterisk. The second PRI is set up as a 5ESS trunk so that the Nortel will accept caller ID from Asterisk and is used only for calls from Asterisk to the Nortel. If you need more specific details, let me know. Regards, -- Anthony Rodgers Business Systems Analyst District of North Vancouver Web: http://www.dnv.org RSS Feed: http://www.dnv.org/rss.asp On Mar 22, 2006, at 3:21 PM, Greg Camp wrote: Hello all, I have Asterisk 1.2.1 and a TE110P connected to a Nortel Meridian Option 81C system. The PRI line is currently setup as DMS100. Here are the relevant lines from zaptel.conf and zapata.conf: zaptel.conf: span=1,1,0,esf,b8zs bchan=1-23 dchan=24 loadzone = us defaultzone = us zapata.conf: [channels] language=en context=from-internal musiconhold=default switchtype=dms100 resetinterval=72000 signalling=pri_net channel=1-23 The Asterisk box will see the call setup message, but according to the d-channel trace (below) a RELEASE(77) message happens shortly after the CALL PROCEEDING(2) message. The effect is that calls between the two systems do not happen. Can someone versed in d-channel messages determine what is going on here? Also, is there any way to tell the Zaptel card to emulate a particular release version for DMS100? I believe the Meridian is expecting Release 36, or something like that (we've tried leaving Release ID blank on the Meridian side with the same results). Protocol Discriminator: Q.931 (8) len=42 Call Ref: len= 1 (reference 20/0x14) (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 14] 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: 20 ] [28 0a b1 47 52 45 47 20 43 41 4d 50] Display (len=10) Charset: 31 [ GREG CAMP ] [6c 06 09 80 34 32 32 34] Calling Number (len= 8) [ Ext: 0 TON: Unknown Number Type (0) NPI: Private Numbering Plan (9) Presentation: Presentation permitted, user number not screened (0) '4224' ] [70 05 e9 34 39 39 31] Called Number (len= 7) [ Ext: 1 TON: Abbreviated number (6) NPI: Private Numbering Plan (9) '4991' ] -- Making new call for cr 20 -- Processing Q.931 Call Setup -- Processing IE 4 (cs0, Bearer Capability) -- Processing IE 24 (cs0, Channel Identification) -- 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 20/0x14) (Terminator) Message type: CALL PROCEEDING (2) [18 03 a9 83 94] 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: 20 ] -- Accepting call from '4224' to '4991' on channel 0/20, span 1 Protocol Discriminator: Q.931 (8) len=8 Call Ref: len= 1 (reference 20/0x14) (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: Unknown (100), class = Protocol Error (6) ] -- Processing IE 8 (cs0, Cause) -- Channel 0/20, span 1 got hangup -- Executing Macro(Zap/20-1, exten-vm|novm|4991) in new stack -- Executing Macro(Zap/20-1, user-callerid) in new stack -- Executing DBget(Zap/20-1, AMPUSER=DEVICE/4224/user) in new stack -- DBget: varname=AMPUSER, family=DEVICE, key=4224/user -- DBget: Value not found in database. -- Executing Macro(Zap/20-1, hangupcall) in new stack -- Executing ResetCDR(Zap/20-1, w) in new stack -- Executing NoCDR(Zap/20-1, ) in new stack -- Executing Wait(Zap/20-1, 5) in new stack == Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'Zap/20-1' in macro 'hangupcall' == Spawn extension (from-internal, h, 1) exited non-zero on 'Zap/20-1' NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request Protocol Discriminator:
