[asterisk-bugs] [LibPRI 0015604]: [patch] Support for called_party_subaddr, currently only calling_party_subaddr is supported

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15604 
====================================================================== 
Reported By:                alecdavis
Assigned To:                rmudgett
====================================================================== 
Project:                    LibPRI
Issue ID:                   15604
Category:                   NewFeature
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2009-07-28 21:51 CDT
Last Modified:              2009-08-04 18:51 CDT
====================================================================== 
Summary:                    [patch] Support for called_party_subaddr, currently
only calling_party_subaddr is supported
Description: 
Looking at q931.c it only has dump_called_party_subaddr
it's missing receive_called_party_subaddr, transmit_called_party_subaddr,
and associated pri_call changes. Maybe more...

The Telecom Specs in NZ suggests that SUB ADDRESS is always on, so doing
"desk to desk" between offices each with an asterisk box over the ISDN
should then be possible, without a whole load of DDI numbers required.

Is there any work beinging done for this?


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0001877 Useful enhancement to chan_zap would be...
====================================================================== 

---------------------------------------------------------------------- 
 (0108630) rmudgett (administrator) - 2009-08-04 18:51
 https://issues.asterisk.org/view.php?id=15604#c108630 
---------------------------------------------------------------------- 
As a workaround to the race condition you have seen, a simple wait in the
dialplan will allow the channel variables to be set.  The thread processing
the dialplan is started by dahdi_new() for en-block calls before the
CALLINGSUBADDR, USERUSERINFO, ANI2, CALLEDTON, and PRIREDIRECTREASON
channel variables are set.

Extending CALLERID/CONNECTEDLINE/REDIRECTING is a good idea.  However,
Asterisk core needs to be enhanced to support subaddresses in the manner of
issue 8824 (COLP support).  Also, how call transfers are handled and the
possibility that a subaddress could be encoded in BCD need to be taken into
consideration.

That being said it should not be too difficult to add subaddressing
support to the core.  Building upon the work done in issue 8824 and issue
14068, the following could be done:
1) Define an ast_party_subaddress struct similar to the
pri_party_subaddress struct in issue14068.
2) Add an ast_party_subaddress subaddress; field to ast_party_id.
3) Add support helper routines similar to the routines for ast_party_id in
channel.c.
4) The BCD encoded subaddress can be converted to ASCII hex so the
dialplan can manipulate it.  (Basically if the subaddress type is
user_specified.)
5) Enhance CALLERID/CONNECTEDLINE/REDIRECTING dialplan functions.
6) Add support in chan_dahdi/libpri.  See the team/group/issue14068
branches where a lot of infrastructure is now available to support
subaddressing better.

I am getting issue 14068 ready to be merged into trunk. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-04 18:51 rmudgett       Note Added: 0108630                          
======================================================================