[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-10-05 12:22 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0111861) rmudgett (administrator) - 2009-10-05 12:22
 https://issues.asterisk.org/view.php?id=15604#c111861 
---------------------------------------------------------------------- 
func_connectedline.c does not need and should not have the dnid-subaddress
series.

func_callerid.c is where the dnid-subaddress series must be because
CALLERID() already manipulates dnid.  The struct ast_callerid became a
catchall for various parties involved in a call and as a result so did
CALLERID().

I do not have a real preference for the separator between number and
subaddress.  I picked ':' because it seems to be available and is a good
separator for the purpose.  However, using '*' would impose an unnecessary
limitation.  The dialplan could be made to accept a number*subaddress
format dialed by a user phone and convert to number:subaddress.  Where as,
if the number*subaddress format were imposed, it would be difficult to use
the '*' for anything else.  Were those bygone era PABX's analog?  If they
were ISDN were they even using the subaddress ie's?

We probably want to be able to add a prefix to the subaddress to encode
the subaddress type and odd/even flag.  Prefix: n for NSAP (default if no
prefix), U/u for user_specified with the case being the odd/even flag.

It is sig_pri.c:sig_pri_call() that will deal with the separation of the
number and subaddress from the Dial application.

Q.931 says that when interworking with X.25 networks, BCD should be
applied.  X.25 indicates that BCD for 12345 is 12 34 50.  The odd padding
will only have any effect in asterisk if the hex string in the asterisk
dialplan is really an odd length.  Otherwise, the odd padding should be
passed through asterisk transparently and handled by the endpoints.  If the
ultimate endpoint is an asterisk box then it is the dialplan that should
determine the encoding. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-05 12:22 rmudgett       Note Added: 0111861                          
======================================================================