[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 
JIRA:                        
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-09-25 12:07 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0111377) rmudgett (administrator) - 2009-09-25 12:07
 https://issues.asterisk.org/view.php?id=15604#c111377 
---------------------------------------------------------------------- 
asterisk_subaddr.diff.txt:
*  The changes for CALLINGSUBADDR and CALLEDSUBADDR are fine for
intermediate purposes, but should not be in the final commit.
*  I have added an appropriate struct ast_party_subaddress to channel.h in
the asterisk/team/rmudgett/subaddr branch and added it to the necessary
structures.

What is needed for asterisk:
*  Add ast_party_subaddress_xxx() structure manipulation functions in
channel.c similar to ast_party_id_xxx().  Also since the subaddress is a
member of ast_party_id the ast_party_id_xxx() functions need to use the
corresponding ast_party_subaddress_xxx() function to handle the subaddress
element.
*  ast_connected_line_build_data(), ast_connected_line_parse_data(),
ast_redirecting_build_data(), and ast_redirecting_parse_data() need to be
updated for the new subaddress elements.
*  ast_party_caller_copy(), ast_party_connected_line_collect_caller(),
ast_connected_line_copy_from_caller(), and
ast_connected_line_copy_to_caller() need to be updated.
*  With two subaddress elements added to struct ast_callerid these new
elements need to be taken care of by free_cid() by calling
ast_party_subaddress_free().
*  func_callerid.c, func_connectedline.c, func_redirecting.c need to be
updated to add access to the new subaddress elements.

These changes are most of what is necessary for the core to handle the new
subaddress elements.  Then it is up to the various channel drivers to
supply and use the information.

libpri_subaddr.diff.txt:
*  Inside libpri, the code does not need to be written conditional upon
POSSIBLE_FUTURE_SUBADDRESS_SUPPORT.  The existing code conditional upon
POSSIBLE_FUTURE_SUBADDRESS_SUPPORT needs to be made unconditional.  The
POSSIBLE_FUTURE_SUBADDRESS_SUPPORT conditional is present because I did not
want to add more subaddressing feature changes than necessary with the COLP
feature.
*  In libpri.h: pri_event_ring leave the existing elements alone.  They
must stay for backward compatibility.  Instead add the struct
pri_party_subaddress calling_subaddress and called_subaddress to the end of
the structure.  New code will use those instead.
*  The pri_sr_set_calling_subaddress() and pri_sr_set_called_subaddress()
should take a pointer to a struct pri_party_subaddress.  Also these
functions are calling q931_party_id_init().  That is initializing too much.
 They should just initialize the subaddress element of the q931_party_id if
desired before converting the data in pri_party_subaddress to
q931_party_subaddress.
*  In pri_internal.h:  The callingsubaddr element of struct q931_call
needs to be removed.  It is now part of the struct q931_party_address
called element of q931_call.
*  A series of q931_party_subaddress_xxx() needs to be created similar to
the q931_party_number_xxx() series.
*  Changes need to be added to q931_party_id_xxx() to reflect that the
structure now contains a subaddress element and should call the appropriate
q931_party_subaddress_xxx().
*  receive_calling_party_subaddr() needs to be modified to update
remote_id.subaddress.
*  static int setup_ies[]  Need to make sure that the new ie's are put in
numerical order per Q.931.

That should be enough for now. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-25 12:07 rmudgett       Note Added: 0111377                          
======================================================================