[asterisk-users] A problem about digium TE220B
Jared Smith
jsmith at digium.com
Tue Feb 19 05:48:06 CST 2008
On Tue, 2008-02-19 at 17:59 +0800, sunxiujun26 at sina.com wrote:
> hello everyone,
> I have a trixbox server with an E1 card(not digium).It connects
> to an AVAYA pbx use E1. It works fine.But when i change the E1 card to
> digium TE220B,there is a problem. When sip extension A(on trixbox)
> call PSTN extension B(on avaya),A must wait longtime before B start to
> ring.From the log I find there are two times call. I don't know why
> the first request be rejected while the second request can get correct
> response.Because the data of the two requests are same !
>From looking at the logs below, I"m not sure if this has anything to do
with the T1/E1 card at all. That being said, please remember that
Digium cards come with installation support from Digium, so if we can't
figure out your problem here on the mailing list, feel free to call our
support line.
Let me start by saying I'm not a Q.931 expert by any stretch of the
imagination, but let me point out a couple of things in the log below:
>
> here is the log(84268599 call 6947):
> ########################### log ### begin ###############
> -- Making new call for cr 34787
> > Protocol Discriminator: Q.931 (8) len=34
> > Call Ref: len= 2 (reference 2019/0x7E3) (Originator)
> > Message type: SETUP (5)
> > [04 03 80 90 a3]
> > 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: A-Law (35)
> > [18 03 a9 83 81]
> > 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 ]
> > [6c 0a 00 80 38 34 32 36 38 35 39 39]
> > Calling Number (len=12) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
> > Presentation: Presentation permitted, user number not screened (0) '84268599' ]
> > [70 05 80 36 39 34 37]
> > Called Number (len= 7) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '6947' ]
> < Protocol Discriminator: Q.931 (8) len=10
> < Call Ref: len= 2 (reference 2019/0x7E3) (Terminator)
> < Message type: SETUP ACKNOWLEDGE (13)
>
>
> < [18 03 a9 83 81]
> < 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 ]
> -- Processing IE 24 (cs0, Channel Identification)
> asterisk1*CLI>
> asterisk1*CLI>
> asterisk1*CLI>
> < Protocol Discriminator: Q.931 (8) len=5
> < Call Ref: len= 2 (reference 2019/0x7E3) (Terminator)
> < Message type: CALL PROCEEDING (2)
> asterisk1*CLI>
> asterisk1*CLI>
> < Protocol Discriminator: Q.931 (8) len=13
> < Call Ref: len= 2 (reference 2019/0x7E3) (Terminator)
> < Message type: DISCONNECT (69)
> < [08 02 83 9c]
> < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Transit network (3)
> < Ext: 1 Cause: Invalid number format (28), class = Normal Event (1) ]
> < [1e 02 84 88]
> < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the remote user (4)
> < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
> -- Processing IE 8 (cs0, Cause)
> -- Processing IE 30 (cs0, Progress Indicator)
> NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
> > Protocol Discriminator: Q.931 (8) len=9
> > Call Ref: len= 2 (reference 2019/0x7E3) (Originator)
> > Message type: RELEASE (77)
> > [08 02 81 9c]
> > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> > Ext: 1 Cause: Invalid number format (28), class = Normal Event (1) ]
Hmmmn... the Avaya seems to be disconnecting the call due to an "invalid
number format".
> < Protocol Discriminator: Q.931 (8) len=5
> < Call Ref: len= 2 (reference 2019/0x7E3) (Terminator)
> < Message type: RELEASE COMPLETE (90)
> NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
> NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
> recordingcheck|20080214-190017|1202986798.5961: Outbound recording enabled.
> recordingcheck|20080214-190017|1202986798.5961: CALLFILENAME=OUT3599-20080214-190017-1202986798.5961
> -- Making new call for cr 33267
> > Protocol Discriminator: Q.931 (8) len=34
> > Call Ref: len= 2 (reference 499/0x1F3) (Originator)
> > Message type: SETUP (5)
> > [04 03 80 90 a3]
> > 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: A-Law (35)
> > [18 03 a9 83 82]
> > 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: 2 ]
> > [6c 0a 00 80 38 34 32 36 38 35 39 39]
> > Calling Number (len=12) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
> > Presentation: Presentation permitted, user number not screened (0) '84268599' ]
> > [70 05 80 36 39 34 37]
> > Called Number (len= 7) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '6947' ]
> < Protocol Discriminator: Q.931 (8) len=10
> < Call Ref: len= 2 (reference 499/0x1F3) (Terminator)
> < Message type: CALL PROCEEDING (2)
> < [18 03 a9 83 82]
> < 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: 2 ]
> -- Processing IE 24 (cs0, Channel Identification)
> < Protocol Discriminator: Q.931 (8) len=9
> < Call Ref: len= 2 (reference 499/0x1F3) (Terminator)
> < Message type: ALERTING (1)
> < [1e 02 81 88]
> < Progress Indicator (len= 4) [ 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) ]
> -- Processing IE 30 (cs0, Progress Indicator)
> ########################### log ### end ###############
This looks pretty much exactly the same to me, except it came down
channel 2 instead of channel 1 on the PRI circuit. Is it possible
you've got the channels mis-configured on the Avaya side? I can't see
any other reason the calls would be handled differently.
--
Jared Smith
Community Relations Manager
Digium, Inc.
More information about the asterisk-users
mailing list