[asterisk-dev] q931 decoding question

Matthew Fredrickson creslin at digium.com
Fri Jan 11 10:39:07 CST 2008


Klaus Darilion wrote:
> Hi!
> 
> Please take a look at the following incoming SETUP message:
> 
> < Protocol Discriminator: Q.931 (8)  len=42
> < Call Ref: len= 2 (reference 5566/0x15BE) (Originator)
> < Message type: SETUP (5)
> < [04 02 88 90]
> < Bearer Capability (len= 4) [ Ext: 1  Q.931 Std: 0  Info transfer 
> capability: Unrestricted digital information (8)
> <                              Ext: 1  Trans mode/rate: 64kbps, 
> circuit-mode (16)
> <                              Ext: 0  User information layer 1: Unknown 
> (24)
> 
> lets decode it:
> 
>        bearer capability IE
>       /
>      /  length
>     |  /
>     |  |   ext=1, coding standard=0 0=ITU, information tranfer 
> capability=0 1 0 0 0=Unrestricted digital information
>     |  |  /
>     |  |  |    ext=1, transfer mode=0 0=circuit mode, information
>     |  |  |    transfer rate=0 0 0 0 0
>     |  |  |  /
>     |  |  |  |
> < [04 02 88 90]
> 
> this means the bearer capability IE does not include the user 
> information layer 1 octet. Nevertheless it gets parsed.
> 
> <                     Ext: 0  User information layer 1: Unknown (24)
> 
> My questions: Why does it gets parsed? Why is it set to 24? I checked 
> libpri source code but could not find the relevant code. Maybe someone 
> can point to the corresponding code.

This looks like a bug in the Q.931 dumping code.  After I looked into 
it, I saw that an oversight was made in the bearer_capability_dump 
routine that is assume a length that doesn't include the IE name and 
length in the length passed to it.  The bug was not present in the 
bearer_capability_transmit routine, but on the off chance there might be 
something like this elsewhere, I saw something similar in the _receive 
routine and fixed it as well.  The bug in the receive routine appears to 
be benign because of the way we're using it in Asterisk.  Please update 
to latest 1.2, 1.4, or trunk from svn to see if it is fixed now.

-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.



More information about the asterisk-dev mailing list