thr3ads.net - asterisk users - [asterisk-users] A problem about digium TE220B [Feb 2008]

If this information is useful, please help other people find it:
Share via:

sunxiujun26 at sina.com

2008-Feb-19 09:59 UTC

[asterisk-users] A problem about digium TE220B

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 !
     I holp some of you can tell me why ,thank you very much!
     

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) ]< 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 ###############



-------------------------------------------------------------------
??????????"???? ????"(
http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2008/mail_zhuiyu_20080218.html )

==================================================================??????????????????????http://bbs.bj.sina.com.cn/tableforum/App/index.php?bbsid=143&subid=0&ismain=1?

Jared Smith

2008-Feb-19 11:48 UTC

head link

[asterisk-users] A problem about digium TE220B

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 dowith 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.

Maybe Matching Threads

Search for more possibly parallel threads

asterisk users - Feb 2008 - A problem about digium TE220B

[asterisk-users] A problem about digium TE220B

[asterisk-users] A problem about digium TE220B

Maybe Matching Threads