[Home]

Summary:ASTERISK-00299: Latest CVS causes D channel handling to go south with TE410P
Reporter:Ryan Tucker (rtucker)Labels:
Date Opened:2003-09-24 00:36:12Date Closed:2011-06-07 14:00:59
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Greetings...

I moved Asterisk to another server, along with our TE410P card.  All was well, until I attempted to call my SIP phone from the outside world.  The SIP phone would indicate the call is answered, while the cellphone would keep ringing, and hanging up either end wouldn't reflect anything.  From that point forward, outbound calls just kind of hang, and inbound calls just ring without doing anything.

The restart command from the console does nothing; the actual pid needs killed.  Many other commands seem to work OK from the console, however.

****** ADDITIONAL INFORMATION ******

Here's what shows up on console, with pri debug set.  Other configs and such available upon request; I'll probably be giving this another shot tomorrow night, so any helpful things to try will be tried then.  :-)

< Protocol Discriminator: Q.931 (8)  len=65
< Call Ref: len= 2 (reference 636/0x27C) (Originator)
< Message type: SETUP (5)
< Bearer Capability (len= 3) [ 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)
< 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: 15 ]
< Facility (len=21) [ < Facility (len=21) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x0f, 0x02, 0x01, 0x01, 0x06, 0x07, 0x2a, 0x86, 'H', 0xce, 0x15, 0x00, 0x04, 0x0a, 0x01, 0x00< Facility (len=21) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x0f, 0x02, 0x01, 0x01, 0x06, 0x07, 0x2a, 0x86, 'H', 0xce, 0x15, 0x00, 0x04, 0x0a, 0x01, 0x00 ]
< Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation allowed of network provided number (3) '5853505727' ]
< Called Number (len=13) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '5854199895' ]
-- Making new call for cr 636
-- Processing Q.931 Call Setup
-- Processing IE 4 (Bearer Capability)
-- Processing IE 24 (Channel Identification)
-- Processing IE 28 (Facility)
-- Processing IE 108 (Calling Party Number)
-- Processing IE 112 (Called Party Number)
   -- Executing SetMusicOnHold("Zap/87-1", "bumper") in new stack
   -- Executing Macro("Zap/87-1", "stdexten|SIP/netacc-9895|netacc|9895") in new stack
   -- Executing LookupCIDName("Zap/87-1", "") in new stack
   -- Changed Caller*ID to "Ryan Tucker" <5853505727>
   -- Executing NoOp("Zap/87-1", "") in new stack
   -- Executing SetAccount("Zap/87-1", "netacc") in new stack
   -- Executing DBget("Zap/87-1", "foo=FEAT/5854199895/PRIVMGR") in new stack
   -- DBget: varname=foo, family=FEAT, key=5854199895/PRIVMGR
   -- DBget: set variable foo to 1
   -- Executing PrivacyManager("Zap/87-1", "") in new stack
   -- CallerID Present: Skipping
   -- Executing DBget("Zap/87-1", "fwdexten=FEAT/5854199895/CFWD/CFU") in new stack
   -- DBget: varname=fwdexten, family=FEAT, key=5854199895/CFWD/CFU
   -- DBget: Value not found in database.
   -- Executing Goto("Zap/87-1", "s|10") in new stack
   -- Goto (macro-stdexten,s,10)
   -- Executing Dial("Zap/87-1", "SIP/netacc-9895|20|r") in new stack
   -- Called netacc-9895
   -- Accepting call from '5853505727' to '5854199895' on channel 15, span 4
> Protocol Discriminator: Q.931 (8)  len=14
> Call Ref: len= 2 (reference 33404/0x827C) (Terminator)
> Message type: SETUP ACKNOWLEDGE (13)
> 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: 15 ]
> Progress Indicator (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
> Protocol Discriminator: Q.931 (8)  len=10
> Call Ref: len= 2 (reference 33404/0x827C) (Terminator)
> Message type: CALL PROCEEDING (2)
> 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: 15 ]
> Protocol Discriminator: Q.931 (8)  len=14
> Call Ref: len= 2 (reference 33404/0x827C) (Terminator)
> Message type: ALERTING (1)
> 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: 15 ]
> Progress Indicator (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8)  len=12
< Call Ref: len= 2 (reference 636/0x27C) (Originator)
< Message type: STATUS (125)
< Cause (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Message type nonexist. (97), class = Protocol Error (6) ]
< Call State (len= 1) [ Ext: 0  Coding: CCITT (ITU) standard (0) Call state: Call Present (6)
-- Processing IE 8 (Cause)
-- Processing IE 20 (Call State)
< Protocol Discriminator: Q.931 (8)  len=21
< Call Ref: len= 2 (reference 636/0x27C) (Originator)
< Message type: FACILITY (98)
< Facility (len=14) [ < Facility (len=14) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x08, 0x02, 0x01, 0x01, 0x02, 0x01, 0x00, 0x84, 0x00< Facility (len=14) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x08, 0x02, 0x01, 0x01, 0x02, 0x01, 0x00, 0x84, 0x00 ]
-- Processing IE 28 (Facility)
(inbound call just rings and rings, asterisk doesn't do anything here)
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 636/0x27C) (Originator)
< Message type: DISCONNECT (69)
< Cause (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Processing IE 8 (Cause)
(note the lack of anything doing with the disconnect.  eeeeep.)
   -- Starting simple switch on 'Zap/12-1'
   -- Executing NoOp("Zap/12-1", "") in new stack
   -- Executing DigitTimeout("Zap/12-1", "5") in new stack
   -- Set Digit Timeout to 5
   -- Executing ResponseTimeout("Zap/12-1", "10") in new stack
   -- Set Response Timeout to 10
 == CDR updated on Zap/12-1
   -- Executing SetCallerID("Zap/12-1", "5854198200") in new stack
   -- Executing SetAccount("Zap/12-1", "netacc") in new stack
   -- Executing Goto("Zap/12-1", "rochnyint|93505727|1") in new stack
   -- Goto (rochnyint,93505727,1)
   -- Executing Dial("Zap/12-1", "Zap/g4/3505727") in new stack
-- Making new call for cr 32770
> Protocol Discriminator: Q.931 (8)  len=46
> Call Ref: len= 2 (reference 2/0x2) (Originator)
> Message type: SETUP (5)
> Bearer Capability (len= 3) [ 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)
> 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: 1 ]
> Display (len= 1) [ > Display (len= 1) [ 1> Display (len= 1) [ 1 ]
> Progress Indicator (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
>                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
> Calling Number (len=14) [ Ext: 0  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)
>                           Presentation: Presentation permitted, user number passed network screening (1) '5854198200' ]
> Called Number (len=10) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0) '3505727' ]
   -- Called g4/3505727
(and then this call just hangs... can't hang it up at all)
voip2*CLI> show channel Zap/87-1
-- General --
          Name: Zap/87-1
          Type: Zap
      UniqueID: 1064378381.0
     Caller ID: "Ryan Tucker" <5853505727>
   DNID Digits: 5854199895
         State: Ringing (5)
         Rings: 1
  NativeFormat: 68
   WriteFormat: 4
    ReadFormat: 4
1st File Descriptor: 80
     Frames in: 0
    Frames out: 0
Time to Hangup: 0
--   PBX   --
       Context: macro-stdexten
     Extension: s
      Priority: 10
    Call Group: 0
  Pickup Group: 0
   Application: Dial
          Data: SIP/netacc-9895|20|r
         Stack: 1
   Blocking in: (Not Blocking)
voip2*CLI> show channel SIP/netacc-9895-971d
-- General --
          Name: SIP/netacc-9895-971d
          Type: sip
      UniqueID: 1064378381.1
     Caller ID: "Ryan Tucker" <5853505727>
   DNID Digits: (N/A)
         State: Down (0)
         Rings: 0
  NativeFormat: 4
   WriteFormat: 4
    ReadFormat: 4
1st File Descriptor: 95
     Frames in: 0
    Frames out: 0
Time to Hangup: 0
--   PBX   --
       Context: sipoutbound
     Extension:
      Priority: 1
    Call Group: 0
  Pickup Group: 0
   Application: AppDial
          Data: (Outgoing Line)
         Stack: -1
   Blocking in: (Not Blocking)
Comments:By: Mark Spencer (markster) 2003-09-24 08:36:37

Can you find me on IRC?  irc.freenode.net in #asterisk, kram
By: Ryan Tucker (rtucker) 2003-09-24 22:50:02

A couple things from tonight's poking:

1) It's not specific to the latest CVS... I snarfed the sources over from the known-good machine and the behaviour is the same.

2) I'm pretty sure it's a PRI-only problem... calls going via channelized T1's work fine when in the wedged state, it's just all of the PRI's die.

This is making me think it's the box.  The box is a dual-processor 2.4GHz Xeon machine with 1gb of RAM.  It's running Red Hat 9.0.

You appear to have gone walkabout IRC-wise; the nightly billing-o-matic fires up around midnight, so if I don't hear from you within about 15 minutes, I'm moving the board back over to the old server.  :-)  -rt
By: John Todd (jtodd) 2003-09-29 03:09:52

What was the result of moving the board?  Is this problem still evident?
By: Ryan Tucker (rtucker) 2003-10-04 21:01:24

The old server is (and has been for awhile) very OK with this.

I tried a brand-spanking-fresh CVS download tonight, and it's still broken on the new server... I'm going to continue poking at it a bit.  -rt
By: Ryan Tucker (rtucker) 2003-10-04 21:10:56

Crimeny, I'm an idiot.  overlapdial has been previously documented to cause problems with my cellphone dialing in, and, well, I never actually turned it off, despite thinking I actually did.

All seems better now.  Less wedging, more rocking.  -rt
By: John Todd (jtodd) 2003-10-06 14:54:57

Marked as resolved.