[asterisk-dev] ISDN Cause Code 100, Bosch Integral Management Connection

[Klaus Darilion]

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). Libpri contains the following code:
>>>
>>>         static FUNC_SEND(transmit_bearer_capability)
>>>         ...
>>>         	if ((tc & PRI_TRANS_CAP_DIGITAL)&&(pri->switchtype == PRI_SWITCH_EUROISDN_E1)) {
>>>         		/* Apparently EuroISDN switches don't seem to like user layer 2/3 */
>>>         		return 4;
>>>         	}
>>>         	/* add userlayer 1 info */
>>>         
>>> Since you have switchtype=euroisdn in your zapata.conf (as seen in
>>> previous email), this should prevent the user-layer-1 byte to be added.
>>> Maybe you just have to upgrade to a newer version of libpri (and maybe
>>> Asterisk too).
>> 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.

> I've just checked the various libpri branches in svn and while the 1.0
> and 1.4 head do have the "if ((tc & PRI_TRANS_CAP_DIGITAL)..." check, it
> is missing from the 1.2 branch. That is odd!

This is something I also did not understand. E.g. H324M there are 2 
possibilities - either signal UL1 in bearer capability or low layer 
compatibility IE.

I think there were also some fixes with
http://bugs.digium.com/view.php?id=11593

regards
klaus

> I think that revision 523 from some 9 months ago
> (http://svn.digium.com/view/libpri?view=rev&revision=523) is to blame:
> this removed the "(tc & PRI_TRANS_CAP_DIGITAL)" check, maybe without
> wanting to do so since the check is still present in libpri 1.4. (mattf:
> did you remove the check on purpose?)
> 
> If a tc='Video' call needs a user-info-layer 1 octet (never worked with
> video over ISDN, so I have no idea), then the check is slightly wrong
> and
> 
>         if ((tc == PRI_TRANS_CAP_DIGITAL || tc == PRI_TRANS_CAP_RESTRICTED_DIGITAL) && ...
>         
> has to be used instead of
> 
>         if ((tc & PRI_TRANS_CAP_DIGITAL) && ...
>         
> otherwise the check *will* apply to PRI_TRANS_CAP_VIDEO too since the
> transfer caps are an integer, not a single bit:
> 
>         #define PRI_TRANS_CAP_DIGITAL			0x08
>         #define PRI_TRANS_CAP_RESTRICTED_DIGITAL	0x09
>         #define PRI_TRANS_CAP_VIDEO			0x18
> 
> But for Wolfang's problem, the check in any form should work.
> 
> Regards,
> 	Mike