[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-10-15 06:42 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()






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

---------------------------------------------------------------------- 
 (0093682) tomaso (reporter) - 2008-10-15 06:42
 http://bugs.digium.com/view.php?id=13454#c93682 
---------------------------------------------------------------------- 
mattf,
this works so far, but there is one mistake (which I did already in my
provided file) in partly_chane_dahdi.c, line 44: " return -1; "
This return should be deleted, otherwise the 'parameter stripped'
application call in the dialplan,

    DAHDISendCallreroutingFaciltiy(<diverted-to num>)

doesen't work and stops processing / exits (instead of taking the default
parameter values of orig. called num and div. reason to go on):

*********
   -- Executing [10 at e1:1000] DAHDISendCallreroutingFacility("DAHDI/1-1",
"290") in new stack
[Oct 15 14:22:24] WARNING[3968]: chan_dahdi.c:2474
dahdi_send_callrerouting_facility_exec: Callrerouting Facility without
original called number argument
[Oct 15 14:22:24] WARNING[3968]: chan_dahdi.c:2481
dahdi_send_callrerouting_facility_exec: Callrerouting Facility without
diversion reason argument
  == Spawn extension (e1, 10, 1000) exited non-zero on 'DAHDI/1-1'
*********

If you please could do that little change? I think no further testing is
neccessary! 

*********

Regarding the chan_dahdi.conf.sample:
Do you want to comment the

discardremoteholdretrieval=yes|no

parameter as well, or is to specific for you resp. you want to wait for a
libpri fix (and leave this as an undocumented parameter by now)? 


tomaso 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-15 06:42 tomaso         Note Added: 0093682                          
======================================================================