On Fre, 2008-11-14 at 23:31 +0100, Klaus Darilion wrote:
> Michael Neuhauser wrote:
> > On Fre, 2008-11-14 at 16:54 +0100, Klaus Darilion wrote:
> >> Michael Neuhauser schrieb:
> >>> I'm pretty sure that the wrong User information layer 1 byte is to
> >>> blame. Especially since I've tested it with my libpri (version 1.2.2 +
> >>> bristuff 0.3.0.pre1n, already pretty old) and for a digital call, the
> >>> user-layer 1 byte is *not* there (Bearer Capability is only 4 bytes
> >>> long, not 5 as in your SETUP).
> >> There are valid scenarios with digital calls and UL1 - e.g. UMTS video 
> >> calls (H324M)
> > 
> > OK - but transfer capability is 'Video' then, isn't it? I did not say
> > that user info layer 1 octet shall be omitted in all cases, I was only
> > talking about calls where the transfer capability is 'Unrestricted
> > digital information.'
> 
> No. H324M uses unrestricted digital video AND layer1.

You are right (if you meant "digital information" not "digital video").
I've traced a test call from an UMTS video phone, that's coming from the
PSTN:

< [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)
<                              Ext: 1  User information layer 1: G.7xx 384k Video (38)

So user-info-layer 1 octet may NOT be omitted for all '(un)restricted
digital info' SETUPs. Libpri should be OK in this aspect because I've
newer versions than the one I've checked only leave out userl1 if
(transmoderate == TRANS_MODE_PACKET).

Regards,
	Mike