<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.3132" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Thanks for your time,</DIV>
<DIV> </DIV>
<DIV>I have a PRI running between an Asterisk box and a Polycom MGC-50 MCU. When the MGC places an H.320 call (ISDN Video Conferencing), the bearer capability information element of the setup message may or may not contain octet 5, depending on wether the conference is set to use 64K B-Channels or 56K B-Channels (octet 5 is absent for conferences utilizing 64K B-Channels).</DIV>
<DIV> </DIV>
<DIV>Accord to page Note 6 on page 60 of Q.931 (May 1998), octet 5 may be omitted in certain situations:</DIV>
<DIV> </DIV>
<DIV>If the transfer mode is "circuit mode", and if the information transfer capability is "unrestricted<BR>digital information" or "restricted digital information", and if the user information layer 1 protocol is to be identified only to the addressed entity octet 5 shall be omitted. If the transfer mode is packet mode, octet 5 may be omitted. Otherwise, octet 5 shall be present.</DIV>
<DIV> </DIV>
<DIV>A trace of an example 64K B-Channel call is provided below:</DIV>
<DIV> </DIV>
<DIV>< Protocol Discriminator: Q.931 (8) len=41<BR>< Call Ref: len= 2 (reference 23/0x17) (Originator)<BR>< Message type: SETUP (5)<BR>< [04 02 88 90]<BR>< Bearer Capability (len= 4) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)<BR>< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)<BR>< [18 03 a9 83 97]<BR>< Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0<BR>< ChanSel: As indicated in following octets<BR>< Ext: 1 Coding: 0 Number Specified Channel Type: 3<BR>< Ext: 1 Channel: 23 ]<BR>< [6c 0b a1 39 38 39 35 38 34 33 31 33 38]<BR>< Calling Number (len=13) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)<BR>< Presentation: Presentation permitted, user number not screened (0) '9895843138' ]<BR>< [70 0c a1 31 39 37 38 32 39 32 32 38 35 33]<BR>< Called Number (len=14) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '19782922853' ]</DIV>
<DIV> </DIV>
<DIV>The problem is that on the *outbound* leg of the call, IE 4 octet 5 is present, though it has an "undefined" value. As a result, the upstream switch kicks back the call with cause 100...</DIV>
<DIV> </DIV>
<DIV>> Protocol Discriminator: Q.931 (8) len=47<BR>> Call Ref: len= 2 (reference 8/0x8) (Originator)<BR>> Message type: SETUP (5)<BR>> [04 03 88 90 bf]<BR>> Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)<BR>> Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)<BR>> User information layer 1: Unknown (63)<BR>> [18 03 a9 83 97]<BR>> Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0<BR>> ChanSel: As indicated in following octets<BR>> Ext: 1 Coding: 0 Number Specified Channel Type: 3<BR>> Ext: 1 Channel: 23 ]<BR>> [1e 02 80 83]<BR>> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)<BR>> Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ]<BR>> [6c 0c 21 80 39 38 39 35 38 34 33 31 33 38]<BR>> Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)<BR>> Presentation: Presentation permitted, user number not screened (0) '9895843138' ]<BR>> [70 0c 80 31 39 37 38 32 39 32 32 38 35 33]<BR>> Called Number (len=14) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '19782922853' ]<BR>q931.c:3100 q931_setup: call 32776 on channel 23 enters state 1 (Call Initiated)<BR> -- Called G1/19782922853<BR>< Protocol Discriminator: Q.931 (8) len=10<BR>< Call Ref: len= 2 (reference 8/0x8) (Terminator)<BR>< Message type: RELEASE COMPLETE (90)<BR>< [08 03 82 e4 04]<BR>< Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Public network serving the local user (2)<BR>< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]<BR>< Cause data 1: 04 (4)<BR>-- Processing IE 8 (cs0, Cause)<BR>q931.c:3732 q931_receive: call 32776 on channel 23 enters state 0 (Null)<BR> -- Channel 0/23, span 1 got hangup, cause 100<BR>NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null<BR>NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null<BR> -- Hungup 'DAHDI/23-1'<BR> == Everyone is busy/congested at this time (1:0/0/1)<BR> == Auto fallthrough, channel 'DAHDI/124-1' status is 'CHANUNAVAIL'<BR> -- Channel 0/4, span 6 got hangup request, cause 16<BR> -- Hungup 'DAHDI/124-1'<BR></DIV>
<DIV>Note that the cause data is IE 4. Additionally, if I force libpri to omit IE 4 octet 5 for all calls with "Unrestricted Digital" transfer capability... the cause 100 problem goes away.</DIV>
<DIV> </DIV>
<DIV>The simple fix, obviously, would be to omit octet 5 from IE 4 for all calls with unrestricted (or restricted) digital transfer capability. This won't work... since there are times when IE 4 Octet 5 *should* be present for restricted and unrestricted digital calls. A good example of this would be a conference utilizing 56K B-Channels:</DIV>
<DIV> </DIV>
<DIV>< Protocol Discriminator: Q.931 (8) len=43<BR>< Call Ref: len= 2 (reference 29/0x1D) (Originator)<BR>< Message type: SETUP (5)<BR>< [04 04 88 90 21 8f]<BR>< Bearer Capability (len= 6) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)<BR>< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)<BR>< User information layer 1: V.110 Rate Adaption (33)<BR>< Async: 0, Negotiation: 0, User rate: Unknown (0xf)<BR>< [18 03 a9 83 86]<BR>< Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0<BR>< ChanSel: As indicated in following octets<BR>< Ext: 1 Coding: 0 Number Specified Channel Type: 3<BR>< Ext: 1 Channel: 6 ]<BR>< [6c 0b a1 39 38 39 35 38 34 33 31 33 38]<BR>< Calling Number (len=13) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)</DIV>
<DIV> </DIV>
<DIV>In this case, Asterisk doesn't set IE 4 octet 5 for the outbound leg:</DIV>
<DIV> </DIV>
<DIV>> Protocol Discriminator: Q.931 (8) len=47<BR>> Call Ref: len= 2 (reference 11/0xB) (Originator)<BR>> Message type: SETUP (5)<BR>> [04 03 88 90 bf]<BR>> Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)<BR>> Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)<BR>> User information layer 1: Unknown (63)<BR>> [18 03 a9 83 97]<BR>> Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0<BR>> ChanSel: As indicated in following octets<BR>> Ext: 1 Coding: 0 Number Specified Channel Type: 3<BR>> Ext: 1 Channel: 23 ]<BR>> [1e 02 80 83]<BR>> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)<BR>> Ext: 1 Progress Description: Calling equipment is non-ISDN. (3) ]<BR>> [6c 0c 21 80 39 38 39 35 38 34 33 31 33 38]<BR>> Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)<BR>> Presentation: Presentation permitted, user number not screened (0) '9895843138' ]<BR>> [70 0c 80 31 39 37 38 32 39 32 32 38 35 33]<BR>> Called Number (len=14) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '19782922853' ]<BR></DIV>
<DIV>So, basically, the primary issue is that Asterisk doesn't copy layer 1 capabilities from the inbound leg of a call to the outbound leg of a call. I am aware that there is a patch for this (10217) that is pretty close... and I'd like to try to extend that patch to use channel datastores, as well as handle the case where IE 4 octet 5 should be absent.</DIV>
<DIV> </DIV>
<DIV>However, to handle the "absent octet 5" case, I'd need to test the inbound channel to see if IE4 octet 5 was present there. I can't think of a good way to do this with the present libpri (though I'm probably missing something obvious); if IE 4 octet 5 is missing, the userl1 member of the q931_call structure is left un-initialized (which makes sense).</DIV>
<DIV> </DIV>
<DIV>My thinking was that either a "fake" user layer 1 value could be added to mark Octet 5 as absent, or another member... an "octet 5 absent" flag... could be added to q931_call. Adding a flag to q931_call seemed like the best option. I've attached a proposed patch.</DIV>
<DIV> </DIV>
<DIV>Am I headed in the right direction?</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV> </DIV>
<DIV>--TS</DIV>
<DIV> </DIV>
<DIV> </DIV></BODY></HTML>