[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