Summary:	ASTERISK-09891: [patch] proper user information layer 1 handling
Reporter:	klaus3000 (klaus3000)	Labels:
Date Opened:	2007-07-17 04:49:56	Date Closed:	2011-07-26 14:14:36
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_dahdi/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 10217-asterisk-1.4.21.1-unrestricted-digital-llc.patch.txt ( 1) 10217-asterisk-1.4.22-unrestricted-digital-llc.patch.txt ( 2) 10217-asterisk-trunk-unrestricted-digital-llc.patch.txt ( 3) 10217-asterisk-unrestricted-digital-1.4.17.patch ( 4) 10217-asterisk-unrestricted-digital-llc-11595-1.4.17.patch ( 5) ul1-patch_0.1_1.4.4.txt ( 6) ul1-patch_0.1_TRUNK.txt
Description:	Hi! Using Asterisk as H324M Gateway requires correct Q.931 signaling. Currently Asterisk does not care about User Information Layer 1 signaling in Bearer Capability IE. ****** ADDITIONAL INFORMATION ****** This patch adds: - reading and setting of the user information layer 1 using the CHANNEL function. (func_channel.c) - copy the user information layer 1 value from incoming to outgoing call leg. This is needed when an incoming ZAP call is immediately sent out again. (app_dial.c) - change chan_zap to use the defined ulser information layer 1 value when making digital calls instead of setting it always to -1.
Comments:	By: Jason Parker (jparker) 2007-07-17 06:32:01 Is this the same as PRI-1? By: klaus3000 (klaus3000) 2007-07-17 08:46:52 it is related, but not the same (sorry for not mentioning it) ASTERISK-1012189 is the libpri patch ASTERISK-1015217 this one is the patch to asterisk By: klaus3000 (klaus3000) 2007-09-14 10:24:25 Hi! is this the right way to go (extending ast_chan) or should I use channel variables instead (as asked on the devel list)) By: Tzafrir Cohen (tzafrir) 2007-11-25 04:14:52.000-0600 Does this information belong in the zaptel channel struct (zt_pvt)? Recall that zt_pvt represents a long-standing information. The somewhat equivalent of a SIP peer or user. Not the equivalent of an Asterisk channel. By: klaus3000 (klaus3000) 2007-11-26 03:16:22.000-0600 Hi! This patch does not add any new member to ast_chan or zt_pvt structure. It only extends existing code to handle userinformationlayer1 correclty for digital call. Current behavior only deals with a-law/u-law thus does not handle digital calls correctly. userinformationlayer1 is an ast_chan member. Probably this is not the best place for a proprietary ISDN extension but it is there already thus I reused it. It would be better to extend Asterisk to handle digital connection also in core (se the very long discussion on dev-mailinglist (grep for AST_FRAME_DIGITAL) By: Tilghman Lesher (tilghman) 2007-12-14 17:37:49.000-0600 Actually, this patch does exactly that.  It is adding the element to the ast_channel structure.  I would prefer if you did not.  If you want to pass additional items along, use the channel datastores to allocate space for the data. By: Tzafrir Cohen (tzafrir) 2007-12-14 18:07:49.000-0600 The private struct of chan_zap is the permanent, rather than a per-call struct. If the information resides in zt_pvt, when will it need to be reset? If not: where else can it reside? By: klaus3000 (klaus3000) 2007-12-17 04:42:02.000-0600 @corydon76: Sorry, yes you are right. I added UL1 to channel structure. But the channel structure also already contains "transfercapability" which is also a proprietary ISDN parameter. Further, if UL1 is not stored in ast_chan but somehwere inside private channel memory, how can it be retrieved from the second channel? e.g.: -> incoming ZAP call -> UL1 is stored in zt_pvt -> dial plan execution -> Dial(Zap/....) -> outgoing ZAP call -> outgoing zap channel needs to know UL1 of incoming ZAP channel - how can the outgoing zap channel know about the other zap channel which holds the UL1 data? By: Tilghman Lesher (tilghman) 2007-12-17 06:51:21.000-0600 Please look into channel datastores.  It does exactly what you want. By: klaus3000 (klaus3000) 2007-12-17 08:10:45.000-0600 ah, that sounds interesting can you please refer me to some piece of code where this is used (to learn how to use it). By: Tilghman Lesher (tilghman) 2007-12-17 11:32:32.000-0600 func_odbc uses it to store results in multirow mode (trunk only).  func_lock, func_volume, and func_enum also use datastores. By: Tilghman Lesher (tilghman) 2008-01-04 15:41:15.000-0600 Any new patches ready? By: klaus3000 (klaus3000) 2008-01-07 05:39:17.000-0600 Sorry - no time yet. Hopefully this week. One question - signaling ISDN digital can happen in all ISDN channels - not only ZAP, also misdn, chan_capi, visdn..... Can a channel datastore also be used by different channel drivers? By: klaus3000 (klaus3000) 2008-01-09 09:28:38.000-0600 I had no time yet to make a new patch. Meanwhile I aligned the old verison with asterisk 1.4.17 By: klaus3000 (klaus3000) 2008-01-23 02:23:33.000-0600 Hi! I have added 10217-asterisk-unrestricted-digital-llc-11595-1.4.17.patch which still lacks of using channel datastores, but it allows signaling h324m using Low Layer Compatibility IE. For this, also the patch libpri-1.4.7.1-lcc-transmit-receive-patch.txt posted on PRI-21 has to be applied. By: klaus3000 (klaus3000) 2008-02-04 06:49:24.000-0600 @Corydon76: If I understand it right, the datastore will be copied from incoming to outgoing channel (inherited) by Dial() once the outgoing channel has answered the call. Right? In my case this is too late as the outgoing channel needs the ISDN information during call setup. Any suggestions how to solve this? Patching app_dial to inherit before the call is answered? Extending the ast_channel structure? Maybe extending datastores to have differ between datastores which will be inherited immediately and datastatore which will be inherited after answering of the call. By: Tilghman Lesher (tilghman) 2008-02-04 10:37:38.000-0600 Uh, no, it happens in ast_request_and_dial, at the same time as it inherits variables, callerid, and the like.  It does not wait until an Answer event to post the inherited datastores.  So a channel has been requested (meaning the internal structures should have been allocated), but no number should have been dialled yet (which should happen during the ast_call step, which happens AFTER the datastore has been inherited). If you are calling during the request phase, then you're jumping the gun.  You shouldn't start the call process until ast_call calls your call function. By: klaus3000 (klaus3000) 2008-07-22 03:02:47 unfortunately I stil did not have time to change the patch to use channel datastore. Nevertheless I have updated the patch for Asterisk version 1.4.21.1 By: Tilghman Lesher (tilghman) 2008-07-22 08:43:27 Please note that this patch needs to be updated against trunk, where chan_zap no longer exists.  Instead, the new channel name is chan_dahdi. By: Dan Julius (danj) 2008-11-14 23:26:21.000-0600 I've just uploaded a patch for version 1.4.22 and all zap items have been ported to dahdi By: Leif Madsen (lmadsen) 2008-12-05 09:12:40.000-0600 danj: would you have the ability to update this to trunk in order to move this along? By: Dan Julius (danj) 2008-12-05 13:12:17.000-0600 I'll give it a try By: Tilghman Lesher (tilghman) 2009-02-26 12:17:56.000-0600 danj:  it's been 3 months.  Have you made any progress on getting this patch updated to trunk? By: Dan Julius (danj) 2009-03-02 18:40:52.000-0600 Sorry, I forgot about this. I'll try to get it done within the next week. By: Dan Julius (danj) 2009-03-10 17:41:25 I just uploaded the patch. This patch is based on v1.4.21, and required renaming all zap to dahdi, I did not see any other major changes in the relevant code between v1.4.21 and trunk. Unfortunately I don't have a PRI available at the moment to test this. By: klaus3000 (klaus3000) 2009-03-11 03:53:30 As noted above, I think updating the patch is not enough - it should be modified to use the channel datastore. By: Leif Madsen (lmadsen) 2009-03-12 07:40:52 danj: the patch you attached says 'trunk' in the name, but your note says it is based on 1.4.21, which clearly is not trunk. Can you clarify whether the patch is based on 1.4.21, or whether it is based on trunk? By: Dan Julius (danj) 2009-03-12 15:55:45 The patch is for the trunk version. I made it by modifying the the patch for 1.4.21 and changing all ZAP references to DAHDI. By: Frank Waller (explidous) 2009-04-14 03:00:11 I have tested the patch ASTERISK-7295 (AOC forwarding) on 1.4.21.1 and 1.4.24.1 together with the patches for forwarding PRI IE Information PRI-21 and PRI-1 and their prerequisites (which this is one of). They are together in production on a high volume 4 PRI (2*CPE 2*NET) system using Euroisdn and forwarding calls to an other PBX while doing some magic in between... Now allowing for proper forwarding of digital ISDN calls (data) and passing of charge information. Sorry, no way to test on other versions, trunk or without the other patch... (patches did need manual work to apply together but no programming changes) These patches are important for passing calls through to other systems in this way! They really should be included asap... By: Leif Madsen (lmadsen) 2009-04-14 06:59:13 I think this patch still needs to be updated to use channel datastores per klaus3000. Can anyone do that so we can move this along? It seems we have a successful test from explidous. By: klaus3000 (klaus3000) 2009-04-14 11:45:55 AFAIR (I am the author) ASTERISK-7437494 (AOC forwarding) has nothing todo with this one and ASTERISK-1153595 and ASTERISK-1012189. By: Leif Madsen (lmadsen) 2009-04-15 11:32:53 Relationships removed. By: Jeff Peeler (jpeeler) 2009-04-22 18:16:34 What libpri changes are required for this? pri_sr_set_llc is not in libpri, but does appear to be used in 11595. By: klaus3000 (klaus3000) 2009-04-22 23:05:55 In the beginning, this patch here was independet on other patches (just proper UL1 handling). Meanwhile this patch was extended to support signalling of UL1 in Low Layer Compatibility IE too, and thus depends on ASTERISK-1153595. By: Jeff Peeler (jpeeler) 2009-04-23 12:40:17 Well, then there are two ways to move this forward. Either 11595 needs to reopened and brought to completion or the patch here needs to not support the UL1 signaling in the low layer compatibility IE. By: Leif Madsen (lmadsen) 2009-06-01 14:12:58 Pinging this issue as we are looking for feedback from the reporter. Thanks! By: Tilghman Lesher (tilghman) 2009-06-01 14:43:57 lmadsen:  I think we're already committed to getting this in.  The caveat currently is for one of the developers to understand the code sufficiently before committing it, so if there's any bugs, we have someone who can take ownership of the problem. By: Tilghman Lesher (tilghman) 2009-06-02 16:13:56 klaus3000: this patch is not in unified format.  I need the patch in unified format. By: Konrad Rozycki (krdian) 2009-07-09 09:51:09 Is there proper UL1 handling patch for asterisk 1.4.24.1 ? By: Tilghman Lesher (tilghman) 2009-07-09 10:27:11 No, and there won't be, because this is a new feature, and 1.4 is feature-frozen. By: Leif Madsen (lmadsen) 2011-07-26 14:14:36.365-0500 I'm closing this issue because the patches are going to be so significantly old at this point, that someone would pretty much have to redo everything. If someone is interested in that, please open a new issue and submit a patch. Thanks!