[Asterisk-video] Unable to complete negociation on 3G calls
Klaus Darilion
klaus.mailinglists at pernau.at
Thu Jun 25 09:10:35 CDT 2009
Maybe you have 64bit problems? First I would try with 32bit and Asterisk
1.4. Once this works, try 64bit and/or Asterisk 1.6.
Julien Leboeuf schrieb:
> Hello,
>
> I'm also trying to set up a 3G-H324M gateway on Asterisk with fontventa
> librairies but it doesn't seem to be willing to work.
> Contacting you is kind of my last hope since I read almost every thing
> there is to read on the subject..
>
> My config is :
> CentOS 5.3 x64, Asterisk 1.6.0.10 (amr + LLC patched), libpri 1.4.10
> (LLC patched), last sources from fontventa, Digium Card TE420; 3G Phone
> Nokia N70 (said to work)
>
> In app_h324m.c, I commented "ast_cli_register(&cli_debug);" otherwise
> segmentation fault on start.
> In h324m.cpp, I also commented "TIFFReverseBits(buffer,len);" since it
> makes asterisk crash at the beginning of a 3G call.
Probably this will cause problems - if the command would not be needed
it would not be in the code :-)
klaus
> A shame since h245.log is a lot more talkative with TIFFRevers... on.
>
> Sometimes at Asterisk startup, I get this message :
> /usr/sbin/safe_asterisk: line 146: 30356 Segmentation Fault (core
> dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS}
> ${ASTARGS} >&/dev/${TTY} < /dev/${TTY}
> Asterisk ended with exit status 139
> Asterisk exited on signal 11.
> Automatically restarting Asterisk.
> mpg123: no process killed
> ....but Asterisk seems to work anyway.
>
> My problem is that in h324m_loopback() funtion,
> frame=H324MSessionGetFrame(id) always returns NULL, hence I got no
> video, no audio...
>
> Here is my PRI debug :
> < Protocol Discriminator: Q.931 (8) len=41
> < Call Ref: len= 2 (reference 3358/0xD1E) (Originator)
> < Message type: SETUP (5)
> < [04 03 88 90 a6]
> < Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer
> capability: Unrestricted digital information (8)
> < Ext: 1 Trans mode/rate: 64kbps,
> circuit-mode (16)
> < User information layer 1: H.223/H.245
> Multimedia (38)
> < [18 03 a9 83 82]
> < Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0
> Exclusive Dchan: 0
> < ChanSel: As indicated in following octets
> < Ext: 1 Coding: 0 Number Specified Channel Type: 3
> < Ext: 1 Channel: 2 ]
> < [6c 0b 21 83 36 36 34 37 39 32 39 30 34]
> < Calling Number (len=13) [ Ext: 0 TON: National Number (2) NPI:
> ISDN/Telephony Numbering Plan (E.164/E.163) (1)
> < Presentation: Presentation allowed of
> network provided number (3) '664792904' ]
> < [70 05 81 33 30 30 37]
> < Called Number (len= 7) [ Ext: 1 TON: Unknown Number Type (0) NPI:
> ISDN/Telephony Numbering Plan (E.164/E.163) (1) '3007' ]
> < [7c 03 88 90 a6]
> < Low-layer Compatability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer
> capability: Unrestricted digital information (8)
> < Ext: 1 Trans mode/rate: 64kbps,
> circuit-mode (16)
> < User information layer 1: H.223/H.245
> Multimedia (38)
> < [a1]
> < Sending Complete (len= 1)
> -- Making new call for cr 3358
> -- Processing Q.931 Call Setup
> -- Processing IE 4 (cs0, Bearer Capability)
> -- Processing IE 24 (cs0, Channel Identification)
> -- Processing IE 108 (cs0, Calling Party Number)
> -- Processing IE 112 (cs0, Called Party Number)
> -- Processing IE 124 (cs0, Low-layer Compatibility)
> receive_low_layer_compatibility
> LLC User layer 1: H.223/H.245 Multimedia (38)
> -- Processing IE 161 (cs0, Sending Complete)
> q931.c:3751 q931_receive: call 3358 on channel 2 enters state 6 (Call
> Present)
> q931.c:2998 q931_call_proceeding: call 3358 on channel 2 enters state 9
> (Incoming Call Proceeding)
> > Protocol Discriminator: Q.931 (8) len=10
> > Call Ref: len= 2 (reference 3358/0xD1E) (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: As indicated in following octets
> > Ext: 1 Coding: 0 Number Specified Channel
> Type: 3
> > Ext: 1 Channel: 2 ]
> -- Accepting call from '+33664792904' to '3007' on channel 0/2, span 1
> -- Executing [3007 at from-t2:1] Answer("DAHDI/2-1", "") in new stack
> q931.c:3133 q931_connect: call 3358 on channel 2 enters state 8 (Connect
> Request)
> > Protocol Discriminator: Q.931 (8) len=10
> > Call Ref: len= 2 (reference 3358/0xD1E) (Terminator)
> > Message type: CONNECT (7)
> > [18 03 a9 83 82]
> > Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0
> Exclusive Dchan: 0
> > ChanSel: As indicated in following octets
> > Ext: 1 Coding: 0 Number Specified Channel
> Type: 3
> > Ext: 1 Channel: 2 ]
> -- Executing [3007 at from-t2:2] h324m_loopback("DAHDI/2-1", "") in new
> stack
> -- Session cree
> -- Session initialisee
> < Protocol Discriminator: Q.931 (8) len=5
> < Call Ref: len= 2 (reference 3358/0xD1E) (Originator)
> < Message type: CONNECT ACKNOWLEDGE (15)
> q931.c:3911 q931_receive: call 3358 on channel 2 enters state 10 (Active)
> -- Remote UNIX connection
> -- Remote UNIX connection disconnected
> -- Remote UNIX connection
> -- Remote UNIX connection disconnected
> < Protocol Discriminator: Q.931 (8) len=9
> < Call Ref: len= 2 (reference 3358/0xD1E) (Originator)
> < Message type: DISCONNECT (69)
> < [08 02 87 90]
> < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0
> Location: International network (7)
> < Ext: 1 Cause: Normal Clearing (16), class = Normal
> Event (1) ]
> -- Processing IE 8 (cs0, Cause)
> q931.c:4026 q931_receive: call 3358 on channel 2 enters state 12
> (Disconnect Indication)
> -- Channel 0/2, span 1 got hangup request, cause 16
> -- Session terminee
> -- Session detruite
> NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication,
> peerstate Disconnect Request
> q931.c:3149 q931_release: call 3358 on channel 2 enters state 19
> (Release Request)
> > Protocol Discriminator: Q.931 (8) len=9
> > Call Ref: len= 2 (reference 3358/0xD1E) (Terminator)
> > Message type: RELEASE (77)
> > [08 02 81 90]
> > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0
> Location: Private network serving the local user (1)
> > Ext: 1 Cause: Normal Clearing (16), class = Normal
> Event (1) ]
> -- Hungup 'DAHDI/2-1'
> < Protocol Discriminator: Q.931 (8) len=5
> < Call Ref: len= 2 (reference 3358/0xD1E) (Originator)
> < Message type: RELEASE COMPLETE (90)
> q931.c:3966 q931_receive: call 3358 on channel 2 enters state 0 (Null)
> NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
> NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
>
> I don't get disconnected automatically, I hangup myself... the phone is
> waiting video endlessly.
>
> Here is my dialplan :
> exten => _3007,1,Answer()
> exten => _3007,n,h324m_loopback()
> exten => _3007,n,HangUp()
>
> I also tried h324m_gw_answer() and videoloopback(), but it gets blocked
> at h324m_gw_answer().
>
> Here, my h245.log :
> -Init call
> -Sending
> request terminalCapabilitySet {
> sequenceNumber = 1
> protocolIdentifier = 0.0.8.245.0.8
> multiplexCapability = h223Capability {
> transportWithI_frames = FALSE
> videoWithAL1 = FALSE
> videoWithAL2 = TRUE
> videoWithAL3 = FALSE
> audioWithAL1 = FALSE
> audioWithAL2 = TRUE
> audioWithAL3 = FALSE
> dataWithAL1 = FALSE
> dataWithAL2 = FALSE
> dataWithAL3 = FALSE
> maximumAl2SDUSize = 1120
> maximumAl3SDUSize = 1120
> maximumDelayJitter = 0
> h223MultiplexTableCapability = basic <<null>>
> maxMUXPDUSizeCapability = FALSE
> nsrpSupport = TRUE
> mobileOperationTransmitCapability = {
> modeChangeCapability = FALSE
> h223AnnexA = FALSE
> h223AnnexADoubleFlag = FALSE
> h223AnnexB = TRUE
> h223AnnexBwithHeader = FALSE
> }
> }
> capabilityTable = 4 entries {
> [0]={
> capabilityTableEntryNumber = 1
> capability = receiveAndTransmitVideoCapability
> h263VideoCapability {
> qcifMPI = 2
> maxBitRate = 520
> unrestrictedVector = FALSE
> arithmeticCoding = FALSE
> advancedPrediction = FALSE
> pbFrames = FALSE
> temporalSpatialTradeOffCapability = FALSE
> errorCompensation = FALSE
> }
> }
> [1]={
> capabilityTableEntryNumber = 2
> capability = receiveAndTransmitAudioCapability
> genericAudioCapability {
> capabilityIdentifier = standard 0.0.8.245.1.1.1
> maxBitRate = 122
> collapsing = 1 entries {
> [0]={
> parameterIdentifier = standard 0
> parameterValue = unsignedMin 1
> }
> }
> }
> }
> [2]={
> capabilityTableEntryNumber = 3
> capability = receiveAndTransmitAudioCapability g7231 {
> maxAl_sduAudioFrames = 1
> silenceSuppression = TRUE
> }
> }
> [3]={
> capabilityTableEntryNumber = 4
> capability = receiveAndTransmitUserInputCapability iA5String
> <<null>>
> }
> }
> capabilityDescriptors = 1 entries {
> [0]={
> capabilityDescriptorNumber = 1
> simultaneousCapabilities = 2 entries {
> [0]=1 entries {
> [0]=1
> }
> [1]=2 entries {
> [0]=2
> [1]=3
> }
> }
> }
> }
> }
>
> But with TIFFReverse on, the log like more like this :
> [......]
> indication vendorIdentification {
> vendor = h221NonStandard {
> t35CountryCode = 60
> t35Extension = 0
> manufacturerCode = 0
> }
> productNumber = 14 octets {
> 52 4d 2d 38 34 20 28 43 29 4e 6f 6b 69 00 RM-84 (C)Noki.
> }
> versionNumber = 21 octets {
> 56 20 33 2e 30 35 34 36 2e 32 2e 20 31 38 2d 31 V 3.0546.2.
> 18-1
> 31 2d 30 35 00 1-05.
> }
> }^M
> request masterSlaveDetermination {
> terminalType = 128
> statusDeterminationNumber = 16370119
> }^M
> response terminalCapabilitySetAck {
> sequenceNumber = 1
> }^M
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -Sending
> request masterSlaveDetermination {
> terminalType = 160
> statusDeterminationNumber = 3321781
> }^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> SRP_SRP_COMMAND
> Retransmission
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> SRP_SRP_COMMAND
> Retransmission
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -SendClosingFlag^M
> SRP_NSRP_RESPONSE
> -Sending
> response terminalCapabilitySetAck {
> sequenceNumber = 1
> }^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> SRP_SRP_COMMAND
> response masterSlaveDeterminationAck {
> decision = master <<null>>
> }^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> -SendClosingFlag^M
> [....]
> till the crash of *...
>
> And last thing.. during a call :
> *CLI> core show channel DAHDI/3-1
> -- General --
> Name: DAHDI/3-1
> Type: DAHDI
> UniqueID: 1245937556.2
> Caller ID: +33664792904
> Caller ID Name: (N/A)
> DNID Digits: 3007
> Language: fr
> State: Up (6)
> Rings: 1
> NativeFormats: 0x44 (ulaw|slin)
> WriteFormat: 0x4 (ulaw)
> ReadFormat: 0x4 (ulaw)
> WriteTranscode: No
> ReadTranscode: No
> 1st File Descriptor: 17
> Frames in: 497
> Frames out: 496
> Time to Hangup: 0
> Elapsed Time: 0h0m10s
> Direct Bridge: <none>
> Indirect Bridge: <none>
> -- PBX --
> Context: from-t2
> Extension: 3007
> Priority: 2
> Call Group: 0
> Pickup Group: 0
> Application: h324m_loopback
> Data: (Empty)
> Blocking in: ast_waitfor_nandfds
> Variables:
> CALLEDTON=1
> ANI2=0
> TRANSFERCAPABILITY=DIGITAL
>
> CDR Variables:
> level 1: clid=+33664792904
> level 1: src=+33664792904
> level 1: dst=3007
> level 1: dcontext=from-t2
> level 1: channel=DAHDI/3-1
> level 1: lastapp=h324m_loopback
> level 1: start=2009-06-25 15:45:56
> level 1: answer=2009-06-25 15:45:56
> level 1: duration=9
> level 1: billsec=9
> level 1: disposition=ANSWERED
> level 1: amaflags=DOCUMENTATION
> level 1: uniqueid=1245937556.2
>
>
> Can you catch something wrong ? What should I do ? Is using Asterisk
> 1.6.0.10 version, an hopeless choice ? or Centos x64 ?
> I saw people succeding with the same Digium Card or with an Asterisk 1.6...
>
>
> Thanks in advance.
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-video
More information about the asterisk-video
mailing list