[Asterisk-Dev] Asterisk / OpenH323 Bearer-Capability

[Aaron S. Joyner]

Craig Southeren wrote:

>On Thu, 02 Sep 2004 16:36:48 -0400
>"Aaron S. Joyner" <asjoyner at intrex.net> wrote:
>
>  
>
>>I'm currently using Asterisk, and working with a provider to setup an 
>>H.323 gateway connection.  In the process of setting up the H.323 
>>connection, Asterisk (via OpenH323) is sending the wrong 
>>Bearer-Capability, as seen here in the output of a call, with "h.323 
>>trace 4" set.
>>
>>    
>>
>>>      IE: Bearer-Capability = {
>>>        80 90 a5                                           ...
>>>      }
>>>      
>>>
>>If I understand it correctly, this is stating that Asterisk is capable 
>>of handling more than just data - that OpenH323 is fully capable of 
>>passing video codecs, etc.  Unfortunately, I need to reduce what I'm 
>>advertising that I'm capable of doing - as it's confusing the remote 
>>end.  In a perfect world, I need it to say "80 90 a2" or "80 90 a3".
>>    
>>
>
>
>I don't have a copy of Q.931 handy, so I can't decode exactly what this
>means. But the first byte indicate the type of data, and 0x80 means
>speech. If it was set to "unrestricted digital" (i.e. video), then the
>first byte would be 0x88
>  
>
I have since put my hands on Q.931 (see footnote 1), and verified the 
above section.  Thanks very much for the pointer in that direction.

>From memory, the last byte is used to define what kind of number is
>being sent, i.e. whether it is national number or such. To set this byte
>in outgoing SETUP PDUs, you will need to override the
>H323Endpoint::OnSendSignalSetup function and set the bearer caps as
>follows:
>  
>
Apparently the last octet in the Bearer-Capability actually defines the 
user information layer 1 protocol.  Strangely, the setting A5 would seem 
to indicate synchronous (bit 7), in-band negotiation (bit 6), 
recommending G.722 or G.725 7kHz audio (bits 5-1, neither of which are 
supported by Asterisk, OpenH323, or the remote Cisco end we're talking 
to.  I'm sort of surprised that this doesn't cause problems, but since 
it's only a "recommendation" according to the standard, apparently it 
doesn't.  Since it seemed more appropriate (and the other end we're 
testing w/ was fussing about it) we went ahead and set it manually in 
the Asterisk channel handler, as suggested.  A patch to set it 
accordingly is included.  Note that it may restrict future 
interoperability with video, the way it's currently implemented.  I 
didn't know how Asterisk wants to handle video over H.323, and didn't 
have time to dig into it, so I left that alone for the time being.

>BOOL MyH323Connection::OnSendSignalSetup(H323SignalPDU & setupPDU)
>{
>  // set Q.931 parms
>  setupPDU.SetQ931Fields(*this, TRUE, q931Plan, q931Type);
>  return H323Connection::OnSendSignalSetup(setupPDU);
>}
>  
>
The actual call we ended up using was something more like this:

> setupPDU.GetQ931().SetBearerCapabilities(Q931::TransferSpeech, 1, 0, 2);

I have attached a unified diff of the changes, with comments describing 
the fields, in the hopes that it will be useful to someone else.  I 
don't know if it's appropriate for the changes to be integrated 
long-term at the OpenH323 level, or simply in the Asterisk channel driver.

This still didn't solve our end problem (audio not being passed between 
SIP and H.323), but I'll make another post about this in a minute.  :)


1. See page 9-12 at http://smuhandouts.com/F8301/Q931.pdf

-- 
Aaron S. Joyner
System Administrator
Intrex.net Internet Services
(919) 573-5488 x102