Posted: Thu Dec 20, 2007 9:20 am Post subject: [Asterisk-video] [spam]Re: Trouble making outbound h324m vid
Hi Klaus,
I've found the same problem the other day with 1.4.15 I couldn't apply your patch to it and after a few modifications got that same resutl (I think).
I did a quick hac in the q931 negotiation, hardcoding the userlayer information byte to 0XA6, but i don't know were was the problem.
BR
Sergio
----- Original Message -----
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
To: asterisk-video@lists.digium.com
Sent: Thu, 20 Dec 2007 10:07:57 +0100
Subject: [spam]Re: [Asterisk-video] Trouble making outbound h324m video call
Hi Rene!
Do incoming h324m call work?
Could you provide q931 dumps of the incoming and the outgoing call? (use
"pri debug span x" x is your span)
regards
klaus
Rene van Weert schrieb:
Quote:
Hey everyone,
I'm trying to make an outbound call using h324m_call but I keep getting
stuck with the following error:
-- Executing [665@from-sip:1] h324m_call("SIP/2000-08214978",
"666@test <mailto:666@test>") in new stack
-- Executing [666@test:1] Set(" Local/666@test-89ed,2
<mailto:Local/666@test-89ed,2>", "CHANNEL(transfercapability)=VIDEO") in
new stack
-- Executing [666@test:2] NoOp("Local/666@test-89ed,2
<mailto:Local/666@test-89ed,2>", "transfer=VIDEO") in new stack
-- Executing [666@test:3] Set("Local/666@test-89ed,2
<mailto:Local/666@test-89ed,2>", "CHANNEL(userinformationlayer1)=38") in
new stack
-- Executing [666@test:4] NoOp(" Local/666@test-89ed,2
<mailto:Local/666@test-89ed,2>", "ul1=38") in new stack
-- Executing [666@test:5] Dial("Local/666@test-89ed,2
<mailto:Local/666@test-89ed,2>", "Zap/g1/0x") in new stack
-- digital call, setting user information layer 1 to 38 (0x26)
-- Requested transfer capability: 0x18 - VIDEO
-- Called g1/06xxxx
* -- Channel 0/2, span 1 got hangup, cause 100
* -- Hungup 'Zap/2-1'
Cause 100 means the following on a page of isdn cause codes i found:
*Cause No. 100 - Invalid information element contents.*
This cause indicates that the equipment sending this cause has received
and information element which it has implemented; however, one or more
of the fields in the information element are coded in such a way which
has not been implemented by the equipment sending this cause.
What it means:
Like cause 1 and cause 88, this usually indicates that the ISDN number
being dialed is in a format that is not understood by the equipment
processing the call. SPIDs will sometimes fail to initialize with a
Cause 100, or a call will fail with this cause.
Can anyone help me in resolving this problem?
I am running Asterisk 1.4.15 with Digium TE110P 1 span on a KPN (also
tried MCI) E1 line.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum