[asterisk-bugs] [LibPRI 0013454]: [patch] Several libpri issues (bugs/features) regarding ISDN QSIG

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13454 
====================================================================== 
Reported By:                tomaso
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   13454
Category:                   New/Feature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 142290 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-10 05:14 CDT
Last Modified:              2008-09-20 02:26 CDT
====================================================================== 
Summary:                    [patch] Several libpri issues (bugs/features)
regarding ISDN QSIG
Description: 
Feature/Fix 1: Option to select logical/physical PRI QSIG channel mapping
(by parameter in dahdi.conf)
Reason: QSIG - depending on version and manufacturer -  uses two different
ways of channel mapping (Q.931 channel identification) to address
B-channels on a E1.  
a) 1-15, 17-31 (physical channel mapping) (implemented)
b) 1-30 (logical channel mapping) (provided by patch)

Dahdi.conf parameter: qsigchannelmapping = physical | logical 
; default: physical (= old behaviour)


Feature/Fix 2: Support for the extended coding of QSIG name operations
(calling name)
Reason: Libpri 1.6beta1 does only support name presentation in simple
mode
a) ROSE_NAME_PRESENTATION_ALLOWED_SIMPLE (implemented)
b) ROSE_NAME_PRESENTATION_ALLOWED_EXTENDED (provided by patch)
(Siemens HICOM 300 H QSIG V2 does this)


Feature/Fix 3: Option to deactivate MOH (AST_CONTROL_HOLD/UNHOLD frame
towards asterisk) when ISDN notification indicators 'remote hold' or
'remote retrieval' are received (by parameter in dahdi.conf) 
Reason 1:  MOH is already provided by ISDN Network, intermediate Asterisk
MOH towards SIP shall not be used. (provided by patch)
Reason 2 (bug): Libpri is not able to detect notification indicators
outside a Q.931 Notify message. E.g. Notification indicators within a Q.931
Facility message are ignored.
This leads to a never ending MOH when a call is transferred on ISDN
network side followed/indicated by a CTComplete facility indication
including remote retrieval notification. (should by fixed sometimes)

Dahdi.conf parameter: discardremoteholdretrieval = yes | no
;default: no (old behaviour)


Feature/Fix 4: Append a cause to a progress message if it is for releasing
purposes (user busy, congestion)
(Siemens HICOM 300 H QSIG V2 need this to work properly)


Feature 5: A new PRI QSIG application (Dahdi Channel) to execute immediate
QSIG call rerouteing on incoming ISDN/QSIG call (provided by patch)
Reason: The already implemented Call Transfer functionality for QSIG in
libpri 1.6 (sending CTComplete if call is bridged) is unsuitable when
ISDN/QSIG PBX side is not applying a path replacement feature autonomously
to dissolve the loop.

(Silly) Dialplan example (let all incoming calls reroute to 12345 by QSIG
pbx):
exten => _X.,1,DAHDISendCallreroutingFacility(Dahdi/12345)
exten => _X.,n,Wait(5) 
; let QSIG pbx a little time to divert and release the call
exten => _X.,n,Hangup()






====================================================================== 

---------------------------------------------------------------------- 
 (0092724) tomaso (reporter) - 2008-09-20 02:26
 http://bugs.digium.com/view.php?id=13454#c92724 
---------------------------------------------------------------------- 
mattf,
I started testing the bug13454 libpri branch (with the small API change
regarding chan_dahdi/asterisk). The functionality didn't break, so your
changes are o.k.. However I hit on a behaviour regarding the (my) new QSIG
callRerouting function (shame on me). We are testing towards Siemens HiPath
3000 and Hicom 300 H, which generally show different QSIG behaviour
(different product lines) . I would like to make that clear (next week)
before I give the final o.k.. Maybe I have to correct my patches a little
bit.
We are not in such a hurry, so if you don't mind I'll give you the trigger
later to go on.

By the way, you made the 'new' libpri backward compatible. Is it your
intention to do the same with chan_dahdi/asterisk the other way round? I.e.
examine the libpri 'version' in chan_dahdi at build-time to adapt the
proper API calls? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-20 02:26 tomaso         Note Added: 0092724                          
======================================================================