Summary:	ASTERISK-07575: [patch][post 1.4] Implementation of QSIG ETS 300 258 - ISO Path Replacement (ANF-PR)
Reporter:	Keith Ward (kward)	Labels:
Date Opened:	2006-08-21 20:33:22	Date Closed:	2007-06-21 14:05:00
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) anfpr_code_change.txt ( 1) anfpr_rev422trunk.diff ( 2) data23-fulldebug.txt ( 3) path_replacement.c ( 4) PathReplacement.SVNr376.patchGOOD ( 5) PathReplacement.SVNr382.patchUPDATE ( 6) PathReplacement.txt ( 7) pri_debug_prGOOD.txt ( 8) pridebug.txt ( 9) qsig7.txt (10) qsig9.txt (11) route-pat90.zip
Description:	As per closed BugID: 0003554 " mattf - manager 03-10-05 13:11 Call Deflection is a bit of a different service than 2BCT. ECT is just a different form of 2BCT. The problem (from what I understand) is that it is implemented differently on different switch types. I had the standard that was used on ATT5ESS so that's what I implemented. If there is a EuroISDN feature of this type, than if someone has the spec they can do it. I DO know that there is a Q.SIG feature of this type. If someone wants to pay to have it done, I'm sure it can get sped up a bit ;-)   " The Q.SIG feature is called "Path Replacement" (ETS 300 258 - Path Replacement (ANF-PR))and is more generally implemented accross switches than is TBCT/2BCT (which seems to be VERY Avaya specific!).  I have been working with the Q.SIG specs and focusing on Path Replacement as I have a need for it in a specific implementation. The Q.SIG "Path Replacement Feature" requires the following: After both legs of the call are setup and Asterisk has a successful "tromboned" or bridged call ... Asterisk sees both 'B' channels (from trombone) are on same PRI/technology and initiates "Path Replacement" events a. Asterisk sends "Transfer Complete" messages to both call legs b. QSIG Switch sends "Purpose" message on one of the legs (random 1-10sec timer expires - 1st leg to send is it!) c. Asterisk rebroadcasts "Purpose" message to other call leg d. QSIG Switch sends "Disconnect" message on one of the legs (same random timer sequence as above) e. Asterisk rebroadcasts "Disconnect" message to other call leg f. QSIG Switch disconnects Asterisk call legs - callers are now within QSIG switch *** Part-time coder alert! *** I have started the coding (patches attached) based off of what you have implemented for 2BCT (I do a check for QSIG vs. 5ESS SwitchType in the pri.c/pri_channel_bridge() function to launch the appropriate feature).  My pri_facility.c/eect_initiate_pathreplacement() code is a copy of your pri_facility.c/eect_initiate_transfer() function with changes to send "Call Transfer Complete" messages to both channels as stipulated above.  I have successfuly tested all the way up to step (b) above - where I receive a "Purpose" message back ... and this is where I am stuck!  I have addded code to the pri_facility.c/rose_invoke_decode() function to check for a new operation_tag by the name of "SS_ANFPR_PATHREPLACEMENT" (int 4) ... which is the "Purpose" message I am supposed to receive and send onto the other channel. What I need is help with HOW to send this captured "Purpose" message back onto the other channel.  I would assume the "easy hack" would be to wait for the message in the pri_facility.c/eect_initiate_pathreplacement() and continue the messaging in this function.  Can that be done?  How do I "receive" messages (I seem to have send down! ;) )?  Can you point me in the right direction - I am more than happy to continue the coding effort (and have access to two switches/test systems that support this feature).  I just need to know how to get through this next step. Help greatly appreciated and possible [BOUNTY] (please contact me direct for more Bounty info - kward@suffolk.lib.ny.us). ALSO: Sorry for the patch to 1.2.3 - but that is our (current) production build.  If necessary - I can move it forward to an SVN checkout! ****** ADDITIONAL INFORMATION ****** 3 patch files attached (hopefully!) More info on QSIG messages ... "Transfer Complete" message    Following is an ASN.1 decoded ISO Call Tran Complete message and following    that are the hex bytes for this message.   1  13:26:23.740  60 00001517 ==> FAC        crv 1_4048            D-channel port number:                                   00001517            Protocol Discriminator: 08                           call control            Call Reference Value: 02 c0 48                   Destination 4048            Q.931 Message Type: 62                                   Facility       =>   FACILITY inv 22012 prof=0x9f invoke: Call Trans. Complete [ECMA-178]            |  DECODED PDU:            |  value NetworkFacilityExtension ::=            |  {            |    sourceEntity endPINX,            |    destinationEntity endPINX            |  }            |  value InterpretationApdu ::= discardAnyUnrecognisedInvokePdu            |  << Call Trans. Complete [ECMA-178] >>            |  value IeRoseAPDU ::= invoke :            |    {            |      invokeId 22012,            |      opcode local : 12,            |      argument CTCompleteArg :            |      {            |        endDesignation primaryEnd,            |        redirectionNumber presentationRestricted : NULL,            |        callStatus alerting            |      }            |    }                                08 02 C0 48 62 1C 21 9F AA 06 80 01              00 82 01 00 8B 01 00 A1 13 02 02 55 FC 02 01 0C                  30 80 0A 01 00 81 00 0A 01 01 00 00             "Propose" message < Protocol Discriminator: Q.931 (8)  len=46 < Call Ref: len= 2 (reference 2/0x2) (Terminator) < Message type: FACILITY (98) < [1c 27 9f aa 06 80 01 00 82 01 00 a1 1c 02 02 01 1e 02 01 04 30 80 12 01 34 a5 80 0a 01 04 12 05 32 30 30 30 36 00 00 00 00] < Facility (len=41, codeset=0) [ 0x9f, 0xaa, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0xa1, 0x1c, 0x02, 0x02, 0x01, 0x1e, 0x02, 0x01, 0x04, '0', 0x80, 0x12, 0x01, '4', 0xa5, 0x80, 0x0a, 0x01, 0x04, 0x12, 0x05, '20006', 0x00, 0x00, 0x00, 0x00 ] -- Processing IE 28 (cs0, Facility) so the next steps are: 1) tandem the received propose on to the other trunk leg of the call......the only thing that changes is the CRV.......the rest of the message is the same. 2) then you should get a DISConnect message on one leg of the call.....you need to tandem this message on to the other leg of the call changing only the CRV.
Comments:	By: Serge Vecher (serge-v) 2006-08-22 08:33:42 kward: couple of comments here ... 1. Could you please get a disclaimer on file with Digium (see bottom of http://bugs.digium.com/main_page.php) and confirm so with a note here when done? 2. A new feature like this is a candidate for inclusion into SVN trunk, not a release (1.2.x), so we discourage posting patches for releases. I will let the patches stay if you upload trunk patches quickly... See  http://www.asterisk.org/developers/Patch_Howto 3. I would advertise the bounty on the wiki (voip-info.org), as it has more exposure than the bugtracker. Please note, that a dislaimer will be required from any developer contributing code under the bounty. Thanks! By: Keith Ward (kward) 2006-08-22 12:57:40 Updated patches based on today's (8/22/2006) SVN trunk! I have changed the NAME of the pri_facility.c/eect_initiate_pathreplacement() to pri_facility.c/anfpr_initiate_transfer() to better follow the guidelines and characteristics of the LibPri implementation. I have also filled and signed the disclaimer and have faxed to Digium as per VECHERS' request. If there is anyone on BugTracker who is willing to help with implementation - that would be greatly appreciated!  I will be advertising on WiKi as well! By: Keith Ward (kward) 2006-08-22 13:01:16 Note:  Updated patches are *.SVNpatch By: Serge Vecher (serge-v) 2006-08-22 13:37:45 kward: thank you. You may also want to sign up for the asterisk-dev mailing list and email the list with this bug # to see if any other developer could help you with this... By: Manrique Feoli (manrique feoli) 2006-09-13 18:21:43 Hi,  I'm interested in helping on this issue,  at least as far as I can. I've been working on developing Path Replacement with Dialogic Boards, and am very interested to help making it on LibPri. Let me know where and how to start By: Keith Ward (kward) 2006-10-05 21:13:08 *** IT'S WORKING *** The new patches (*.SVNr376_workingpatch) is a working and tested implementation of ISDN Q.SIG Path Replacement to an Avaya 8700 - the Avaya *MUST* use "Route with ARS" (Automatic Route Selection) as well as be configured to accept Path Replacement requests from the ISDN pri. If you have specific questions on Avaya config - I may be of limited help or can, at least, point you in the right direction. SwitchType *MUST* be QSIG in order for LibPri to try a Path Replacement! I hope this is helpful and please provide feedback (either positive or negative) to the patch/code and/or usefullness of this patch & hopefully addition to the LibPri code! By: Keith Ward (kward) 2006-10-05 21:29:32 ... sorry!  pri.c.SVNr376_workingpatch missed an update ... Please use pri.c.SVNr376_workingpatchGOOD instead! (*note to manager:  All files can be removed EXCEPT for:  pri.c.SVNr376_workingpatchGOOD  pri_facility.c.SVNr376_workingpatch  pri_facility.h.SVNr376_workingpatch  pri_internal.h.SVNr376_workingpatch ... for some reason I cannot delete them!) By: Serge Vecher (serge-v) 2006-10-06 09:19:11 kward: can you please combine all patches into one? If you do the svn -diff command on your whole checkout, that should do it --> see the link in my first note for more info... By: Keith Ward (kward) 2006-10-06 09:33:43 svn diff ... very cool, quick ... and Done! Please see PathReplacement.SVNr376.patch for the consolidated patch. By: Keith Ward (kward) 2006-10-06 10:15:53 OK - so I missed the pri.c update again! UGH! Please use:  PathReplacement.SVNr376.patchGOOD (*note to manager: all other files can be deleted!) By: Keith Ward (kward) 2006-10-06 11:51:12 Manrique Feoli: Thank you for the offer to help! Path Replacement is working to (at least!) the Avaya 8700 with the attached patch to this Bug.  If you understand ASN.1 encoding/decoding - some cleanup of my Hacks would be greatly appreciated! Please note this patch is patched to the SVN checkout release (376) NOT to LibPri tarball releases. Let me know if I can be of assistance ... but what I have done is easily viewable (in text form) in the attached patch. By: Andrey Kovalenko (akovalen) 2006-10-11 16:41:21 I am very interested in testing your solution with our Avaya 8300 switch. Can you please explain how to trigger path replacement in Asterisk dialplan. Thanks in advance. By: Keith Ward (kward) 2006-10-12 12:38:09 akovalen: Thank you for your offer to test!  The Q.SIG Path Replacement is tried automatically (AFTER the trombone of 2 call legs on the same PRI) if all of the below parameters are satisfied ... 1.  BOTH channels (inbound and outbound/tranferred) are on SAME pri 2.  PRI is configured in zapata.conf as "switchtype=qsig" and (I also believe is needed) "signalling=pri_cpe" 3.  DIALPLAN (extensions.conf) does a "standard" outdial Dial() command to initiate 2nd, tromboned, leg of call The Path Replacement code will then ... - Send "Transfer Complete" Q.SIG messages to both call legs - Wait for a "Purpose" response from the Q.SIG switch on ONE of the two call legs (based on a 10 second random timer) - Re-broadcast that inbound "Purpose" message to the other call leg - Await disconnect requests on BOTH PRI channels/legs You shoule be able to do a "pri debug span X" (where X is the appropriate span number) to see all of this happen within the Asterisk CLI.  Please also send the output of that Debug if you run into problems. Good luck! -Keith By: Andrey Kovalenko (akovalen) 2006-10-12 17:28:38 Hello Keith, Today I have configured our Avaya 8300 as you have specified with Q.SIG (peer-master) and Asterisk 1.4 with switchtype=qsig and signalling=pri_cpe. I have successfully patched the libpri (rev 376) with your patch, after which I did a rebuild of - zaptel (trunk) - libpri (rev 376) - asterisk (trunk) Unfortunately after the two tromboned calls connect the Transfer Complete step doesn't happen. I have attached a detailed ISDN trace. Could you please take a look at it when you have the time. I am really excited to see this working. Thanks for all your work. Andrey By: Keith Ward (kward) 2006-10-12 18:13:33 Hi Andrey! OK - what you sent in the log is the very START of Path Replacement!  If this is all the logging you received after a successful trombone transfer (and after waiting about 20-30 seconds for Path Replacement to complete AFTER the trombone) then I think you may have a mis-configuration on the Avaya side. Bascially the last 2 messages you have in your attached logging are SENT (>) from me ... they are "Transfer Complete" messages to each call leg.  So Asterisk is now waiting for a "Propose" message back on either call leg which I cannot see in your logging as the logging does not get that far. In general - the logging is missing the ... Propose Propose rebroadcast and 2 disconnects ... that should be below what you sent. Please make sure:  the Avaya *MUST* use "Route with ARS" (Automatic Route Selection) as well as be configured to accept Path Replacement requests from the ISDN pri. I may be able to get you an Avaya build ... but not today. -Keith By: Andrey Kovalenko (akovalen) 2006-10-13 14:36:04 Hello Keith, I have confirmed that my Avaya does not respond with Propose even after a few minutes of waiting. So I have assembled all relevant Avaya settings in the attached file. I confirmed that ARS and Path replacement are allowed. Perhaps you can spot the setting that's off. I really appreciate your help on this. Thanks, Andrey By: Keith Ward (kward) 2006-10-16 22:54:48 Hi Andrey! I can't tell exactly what load you are using but I can tell it is an older load from some of the trunk group layouts... Try this... on page 2 of trunk group 9 change the numbering format from "unk-pvt" to just "unknown"... let me know the results of that please. -Keith By: Manrique Feoli (manrique feoli) 2006-10-17 09:59:15 Hi Keith I'm planning to test this on a Nortel,  probably by next week,  depending on costumer's availability. In the mean time I could set up the testing environment,  do you think the patch would work for an environment other than Lucent? regards Manrique ps Will any of you be at Astricon next week,  so that we could talk a bit more about QSig? By: Andrey Kovalenko (akovalen) 2006-10-17 13:03:51 Hi Keith, You were right - I can't change the unkn-pvt setting to unknown. Current software version shows as R013x.00.1.346.00 Does it mean I need to upgrade the Avaya software? Thanks, Andrey P.S. Manrique -I am not going to Astricon this year. By: Keith Ward (kward) 2006-10-17 13:30:19 HI Manrique! Unfortunatley, it coincides with another conference I must attend.  I will not be there - but have been to the last 2 ... -Keith PS- It SHOULD NOT be platform dependant ... so Nortel should work fine.  I do not have any experience with Nortel switches, though so I will be less of a help from the config perspective.  I am more than happy to look at logging/troubleshoot from the LibPri perspective if you provide. By: jmls (jmls) 2006-11-16 14:50:25.000-0600 can someone at digium confirm that a disclaimer was received so that I can update the status ? thanks. By: Andrey Kovalenko (akovalen) 2006-11-22 15:48:11.000-0600 Hello Keith, I have received a patch from Avaya which is supposed to fix the QSIG call path replacement problem on 8300. I tested it with your patch. Now after the two FACILITY messages you send to Avaya I do get a FACILITY message from Avaya, but it results in the following parsing error: !! Unable to handle ROSE operation 12 [ 00 00 ] - [..] I will attach a more detailed trace of the problem. Another question I had: when you say *MUST* use "Route with ARS" - is it sufficient that ARS routing is accessed with a FAC code for the inbound call or do I need to enable ARS/AAR Dialing Without FAC in the customer options? Thank you for your help.. < Protocol Discriminator: Q.931 (8)  len=41 < Call Ref: len= 2 (reference 6/0x6) (Terminator) < Message type: FACILITY (98) < [1c 22 9f aa 06 80 01 00 82 01 00 8b 01 02 a1 14 02 01 17 02 01 0c 30 0c 0a 01 00 81 00 0a 01 01 02 02 80 07] < Facility (len=36, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8B, 0x01, 0x02, 0xA1, 0x14, 0x02, 0x01, 0x17, 0x02, 0x01, 0x0C, '0', 0x0C, 0x0A, 0x01, 0x00, 0x81, 0x00, 0x0A, 0x01, 0x01, 0x02, 0x02, 0x80, 0x07 ] PROTOCOL 1F AA 0006 (CONTEXT SPECIFIC [10])  80 0001 00 (CONTEXT SPECIFIC [0])  82 0001 00 (CONTEXT SPECIFIC [2]) 8B 0001 02 (CONTEXT SPECIFIC [11]) A1 0014 (CONTEXT SPECIFIC [1])  02 0001 17 (INTEGER: 23)  02 0001 0C (INTEGER: 12)  30 000C (SEQUENCE)    0A 0001 00 (ENUMERATED: 0)    81 0000 (CONTEXT SPECIFIC [1])    0A 0001 01 (ENUMERATED: 1)    02 0002 80 07 (INTEGER: 32775) -- Processing IE 28 (cs0, Facility) Q.932 Network facility extensions component is not handled Q.932 Interpretation component is not handled Handle Q.932 ROSE Invoke component  [ Handling operation 12 ] !! Unable to handle ROSE operation 12 [ 00 00 ] - [..] By: Andrey Kovalenko (akovalen) 2006-11-28 18:06:45.000-0600 Hi Keith, I was wondering if you have the spec for QSIG supplementary services - specifically for QSIG Call Forward unconditionally. If you can implement this feature on Asterisk and test it against Avaya my company can pay you for this feature. (Ideally we are looking for 302 Moved Temporarily in SIP to QSIG Call Forward Uncoditional translation) Please contact me for more detail at akovalen@gmail.com Thanks, Andrey By: Keith Ward (kward) 2006-11-28 22:31:14.000-0600 Hi Andrey! You are right ... I found a miscoded (or more-likely a mis-guessed) hardcoded value that needs to be calculated for the Length of the Invoke PDU I attach to the other call leg.  You can see the mis-match in your logging as: < Protocol Discriminator: Q.931 (8)  len=45 < Call Ref: len= 2 (reference 4/0x4) (Terminator) < Message type: FACILITY (98) < [1c 26 9f aa 06 80 01 00 82 01 00 a1 1b ... ... and I send to the other call leg: > Protocol Discriminator: Q.931 (8)  len=45 > Call Ref: len= 2 (reference 4090/0xFFA) (Terminator) > Message type: FACILITY (98) > [1c 26 9f aa 06 80 01 00 82 01 00 a1 1e ...  (should have been 1b length!) The attched updated patch should resolve your issue - you're real close! Regarding your other issue and FAC for ARS ... my guess is your fine as the Avaya is correctly responding to my request for PR up to this point! (please note:  patch is patched to NEW r382 SVN release as Asterisk requires me to patch to the live SVN) Let me know how it goes! -Keith By: Keith Ward (kward) 2006-11-28 22:56:27.000-0600 Hi Andrey! re: QSIG Call Forward unconditionally I do have access to the Specs and CFU would be a "any reason" forward-ALL scenario ... so it would not work as the response from a SIP 302 - Moved Temporarily. From doing a bit of reading I think what you are after is QSIG Call Forward No Reply/Response (ETSI EN 300 201) ... which is, sort of, the equivalent of a SIP 404 and/or, possibly, a SIP 302 (if we program it such).  This way we can "take" the call ... try it against a SIP INVITE and if/when we get a 302 back we can then initiate the No Reply (I think!) back to the network or switch. I need to do some more reading on this - but I think this better suits what you are trying to do. Please open a new Bug/Feature request and hit me with a note from that Feature ID once it is opened.  We can chat further on it then. -Keith PS- VERY! busy through the new year at this point ... if your need is not immeidate I may be able to help. By: Keith Ward (kward) 2006-11-28 22:59:49.000-0600 To jmls - manager (and Digium) ... Signed & Faxed on August 22, 2006. -Keith By: Andrey Kovalenko (akovalen) 2006-11-29 13:27:15.000-0600 Hello Keith, Thanks for the patch. I tried it today and there's definitely an improvement since Avaya is sending back a bunch of FACILITY messages. However, they result in the following errors ( more detail in qsig9.txt log) -- Processing IE 28 (cs0, Facility) Q.932 Network facility extensions component is not handled Handle Q.932 ROSE reject component Unable to handle return result on switchtype 10! -- Processing IE 28 (cs0, Facility) Q.932 Network facility extensions component is not handled Handle Q.932 ROSE reject component Don't know what to do if first ROSE component is of type 0x5 05 0000 (NULL) -- Processing IE 28 (cs0, Facility) Q.932 Network facility extensions component is not handled Handle Q.932 ROSE reject component Don't know what to do if first ROSE component is of type 0x5 05 0000 (NULL) -- Processing IE 28 (cs0, Facility) Q.932 Network facility extensions component is not handled Handle Q.932 ROSE reject component Don't know what to do if first ROSE component is of type 0x5 05 0000 (NULL) -- Processing IE 28 (cs0, Facility) Q.932 Network facility extensions component is not handled Handle Q.932 ROSE reject component Don't know what to do if first ROSE component is of type 0x5 05 0000 (NULL) Also, a couple of comments on the patch: 1. If I try to build with -Werror I get cc1: warnings being treated as errors pri_facility.c: In function 'rose_invoke_decode': pri_facility.c:1810: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness pri_facility.c:1814: warning: pointer targets in passing argument 1 of 'strcat' differ in signedness pri_facility.c:1814: warning: pointer targets in passing argument 2 of 'strcat' differ in signedness So I disabled Werror :) 2. Initially code dumps core here: pri_message(pri, "!! Unable to handle ROSE operation %d", operation_tag); //dump_apdu (pri, (u_int8_t *)comp, comp->len + 2); so I commented out the second line to make it work. Please can you fix the Handle Q.932 ROSE reject component Don't know what to do if first ROSE component is of type 0x5 as I feel we are making some progress Thanks, Andrey By: Andrey Kovalenko (akovalen) 2006-11-30 16:53:55.000-0600 Hi Keith, Per your suggestion I have opened feature request http://bugs.digium.com/view.php?id=8480 to implement QSIG call diversion in libpri and interop it with SIP 302 Moved Temporarily. Thanks, Andrey By: Serge Vecher (serge-v) 2006-12-01 08:39:55.000-0600 I left a note in 8480 on how to proceed there. Let continue testing the original patch here. By: pj (pj) 2006-12-01 14:33:31.000-0600 sorry for off-topic, but if we talking about QSIG features in asterisk: is caller id name transfer between asterisk/ip phone and pbx/qsig supported? I would like to buy wildcard to connect asterisk to siemens pbx via E1/QSIG, but anyone not clearly answer me, if caller id name will be displayed on ip phone connected to asterisk or pbx. thanks. By: Serge Vecher (serge-v) 2006-12-01 15:42:32.000-0600 pj: the bug-tracker is not a support forum, so please do not use it as such. Somebody from Digium sales team can help you answer your questions before making a  purchase. By: Andrey Kovalenko (akovalen) 2006-12-06 20:16:04.000-0600 Hi Keith, We have annouced a $2000 bounty on wiki for implementing this feature. The only condition - must be able to verify this on Avaya 8300: http://www.voip-info.org/wiki/view/Asterisk+Bounty+QSIG+call+path+replacement Since you are the one who developed this feature can you please help us make it work with 8300 and claim the bounty :) Thanks, Andrey By: Keith Ward (kward) 2006-12-06 23:58:38.000-0600 Hi Andrey! OK - are you sure you patched that last patch correctly?  You should start with a clean/unpatched rev 382 from the SVN and then apply this patch.  Make sure that you did not patch the already patched rev 376 we were working with before. The reason I ask this is because we're really getting to the EXACT same spot as before ... after I send the 2 "Transfer Complete" messgaes (1 to each call leg) I get the "Propose" message back from your switch - good!  But, then, the patch seems to fail ... basically we get from the switch a GOOD propose: < Protocol Discriminator: Q.931 (8)  len=46 < Call Ref: len= 2 (reference 4/0x4) (Terminator) < Message type: FACILITY (98) < [1c 27 9f aa 06 80 01 00 82 01 00 a1 1c 02 02 00 e2 02 01 04 30 80 12 02 31 33 a1 80 0a 01 02 12 04 32 30 34 32 00 00 00 00] < Facility (len=41, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0xA1, 0x1C, 0x02, 0x02, 0x00, 0xE2, 0x02, 0x01, 0x04, '0', 0x80, 0x12, 0x02, '13', 0xA1, 0x80, 0x0A, 0x01, 0x02, 0x12, 0x04, '2042', 0x00, 0x00, 0x00, 0x00 ] ... and then I send back garbage! ... > Protocol Discriminator: Q.931 (8)  len=46 > Call Ref: len= 2 (reference 5298/0x14B2) (Terminator) > Message type: FACILITY (98) > [1c 27 9f aa 06 80 01 00 82 01 00 a1 06 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00] > Facility (len=41, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0xA1, 0x06, 0x02, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ] I have this working in my environment and I send back the proper/same message I receive.  So, it's gotta be something wrong with the patch or the way it was patched.  You also mention complication errors - I don't get thoes either - so still thinking we've got a patching issue! Does that make sense? BTW- thnx for the Bounty - will continue to work on this with you but please understand that this is the busiest time of year for me so money or no money - you're gonna get the same time out of me right now. -Keith By: Keith Ward (kward) 2006-12-07 00:03:47.000-0600 Andrey - also ... Don't know what to do if first ROSE component is of type 0x5 ... is an "erroneous" ROSE return due to our mal-formed Propose return - my guess! Nothing (yet!) to handle there! -Keith By: Andrey Kovalenko (akovalen) 2006-12-07 02:30:02.000-0600 Keith, You are probably right - I must have messed up the patching process somewhere. Let me explain what I did. First I started with a clean checkout of libpri only (asterisk and zaptel remained trunk version of 1.4 - hope that's ok) >svn checkout -r382 http://svn.digium.com/svn/libpri/trunk libpri382 applied patch in the libpri directory >patch . < PathReplacement.SVNr382.patchUPDATE then built libpri >make clean;make install Also, probably not very important, but the distribution of Linux we use is stock Fedora Core 4. Can you please send me your libpri binary to this e-mail (akovalen@gmail.com), so I can quickly test it with our 8300 and then we'll figure out where my patching process went wrong. Thanks! Andrey By: Andrey Kovalenko (akovalen) 2006-12-07 19:51:21.000-0600 Hi Keith, After testing with the binary you sent I can now say - you are brilliant ! Path replacement is working like a charm with our 8300 !!! Will test tomorrow with Nortel as well.. Now I'm curious to find out what I did wrong in the patching process.. I did >svn checkout -r382 http://svn.digium.com/svn/libpri/trunk  libpri382 >patch -p0 < PathReplacement.SVNr382.patchUPDATE >make clean; make install Perhaps you are using a different gcc or linux distribution? I have Linux version 2.6.17-1.2142_FC4 (bhcompile@hs20-bc1-4.build.redhat.com) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Tue What versions of asterisk and zaptel did you build ? I have trunk versions of both. Thanks for your help and support - I know you are very busy. -Andrey By: Serge Vecher (serge-v) 2006-12-08 08:42:11.000-0600 akovalen: as kward has suggested, you need to apply the patch to a clean source base. If you've patched the source earlier, svn checkout will attempt to merge the differences between your patched local version and a "clean" new version from SVN. So, rm the libpri source directory, go through the motions and see what happens. By: Andrey Kovalenko (akovalen) 2006-12-08 20:16:47.000-0600 serge-v: I did start with a clean source base, revision 382. The patch didn't cause any errors. The patched files are attached. When I try to build I get this: cc1: warnings being treated as errors pri_facility.c: In function 'rose_invoke_decode': pri_facility.c:1810: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness pri_facility.c:1814: warning: pointer targets in passing argument 1 of 'strcat' differ in signedness pri_facility.c:1814: warning: pointer targets in passing argument 2 of 'strcat' differ in signedness make: *** [pri_facility.o] Error 1 Keith, can you please diff these files with your sources to see if there is a difference. I still can't see what could go wrong with the patching. Thanks, Andrey By: Keith Ward (kward) 2006-12-10 21:04:23.000-0600 Hi Andrey! I did a diff against my patched (and unpatched - just to make sure) sources and what you sent in the .zip ... a HUGE! difference!  I don't know where your svn doanload went wrong - but you definately did NOT get rev 382.  I had over 1k of diff output :( I tried to duplicate your commands and all worked fine for me (except for the '^' in your svn checkout). Please try the following ... svn checkout -r382 http://svn.digium.com/svn/libpri/trunk libpri382.new cd libpri382.new patch < PathReplacement.SVNr382.patchUPDATE make clean && make && make install ... let me know the outcome! -Keith By: Keith Ward (kward) 2006-12-10 21:10:30.000-0600 BTW - figured out [^] is a Mantis addition ... make sure you take that out of the command line. By: Andrey Kovalenko (akovalen) 2006-12-11 20:47:04.000-0600 Hi Keith, I followed your instructions exactly and the results are the same. What I did this time is I took snapshots of the release 382 files before and after pathching (attached). Can you please diff the pri_facility.c with your sources before the patch. BTW, when I build release 382 before a patch everything builds correctly. This is really strange. Also - when I look at the code after the patch I understand why compiler complains: sprintf(datalen, "0x%x", strlen(data)+4); strlen() expects const char * and data is unsigned char* this code comes from the Patch file, so it makes sense why gcc complains.. [root@asterisk libpri382.new]# patch < PathReplacement.SVNr382.patchUPDATE patching file pri_facility.c patching file pri_facility.h patching file pri.c patching file pri_internal.h [root@asterisk libpri382.new]# make clean && make && make install rm -f *.o *.so *.lo *.so.1 *.so.1.0 rm -f testprilib libpri.a libpri.so.1.0 rm -f pritest pridump rm -f .depend CC=gcc ./mkdep -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g   `ls *.c` gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g     -c -o copy_string.o copy_string.c gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g     -c -o pri.o pri.c gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g     -c -o q921.o q921.c gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g     -c -o prisched.o prisched.c gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g     -c -o q931.o q931.c gcc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g     -c -o pri_facility.o pri_facility.c cc1: warnings being treated as errors pri_facility.c: In function 'rose_invoke_decode': pri_facility.c:1810: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness pri_facility.c:1814: warning: pointer targets in passing argument 1 of 'strcat' differ in signedness pri_facility.c:1814: warning: pointer targets in passing argument 2 of 'strcat' differ in signedness make: *** [pri_facility.o] Error 1 By: Keith Ward (kward) 2006-12-11 22:40:39.000-0600 Hi Andrey! I have no idea what that rev is - but it's not what I've patched to. Please see attched libpri382.tgz (tar/gzipped) ... which is a NON-PATCHED source I downloaded tonight (from the svn as previously described).  It is VERY different from what you have in any of the attached files. You should be able to patch & compile this just fine. -Keith By: Serge Vecher (serge-v) 2006-12-12 10:20:54.000-0600 ok, just as a quick summary here, besides a few problems with the patching process, the PathReplacement.SVNr382.patchUPDATE patch file works fine, right? By: Keith Ward (kward) 2006-12-12 10:41:30.000-0600 Hi serge-v! Yes - I confirmed it back on 11/28 to my Avaya with updates as per conversation with Andrey and his implementation. We also have confirmation from Andrey on his Avaya 8300 as of 12/7. The most recent conversations are strictly around complication/patching/revs. -Keith By: Serge Vecher (serge-v) 2006-12-12 10:49:27.000-0600 mattf: any chance of getting a code review here? By: Donny Kavanagh (donnyk) 2006-12-12 11:54:27.000-0600 Matt's off getting hitched, not sure when he's back. Can someone remove all the useless attachments please. By: Andrey Kovalenko (akovalen) 2006-12-19 13:14:10.000-0600 Hi Keith, I would like to report that we have found the problem with the patch and slightly modified it to work with 8300. It would be great if you tried it on the 8700 as well. I am attaching just the relevant code change right now. Will generate the full diff later. Thanks, Andrey By: Keith Ward (kward) 2006-12-20 12:13:51.000-0600 HI Andrey! Unfortunately, the "fix" you propose does not work in my environment and the reason it does not work is because you have some static data within you message set which pertains to your specific message/switch setup (which, will break, eventually even for you). I made the same exact mistake with my original patch.  I had "hardcoded" a very similar header structure to yours ... unsigned char buf1[] = {0x9f, 0xaa, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0xa1, 0x1d,}; ... but this will only work for a specific message from a specific switch with a given set of parameters (hence, it works for you, for now ;) ). The issue is around the last three bytes ... 0x00, 0xa1, 0x1d  ... the 0x1d you have hardcoded is a "length" indicator for the message set (which changes with many varibles sent from the switch).  You will find that your patch does work for a few days and then, inexplicably, will break/not work due to the switch sending a different length message set. The code I added, specifically:                        buffer[i-3] = (0xa1);                        char datalen[4];                        sprintf(datalen, "0x%x", strlen(data)+4);                        buffer[i-2] = strtoul(datalen, NULL, 16); ... was to "compute" the length from the inbound massage set.  I know that this code gives you problems in compliation ... but what it does is take the current length of the inbound message, converts it to HEX and puts it into the "slot" that you currently have hardcoded as 0x1d.  We are using this code in production on 3 different Aavay switches without incident. My patch, and the library I sent to you, are still a better alternative than your code change above (absolutley no disrespect intended - I appreciate all you help in testing).  What I really need is someone to help me chnage/FIX this piece of code to allow for the dynamic length requirement in HEX, but do it in such a way that it does not complain for you. Thank you. -Keith Note:  I still have not been able to replicate your issues with my patch. By: Keith Ward (kward) 2006-12-20 12:18:06.000-0600 ALL - IF THERE IS SOMEONE WHO COULD DOWNLOAD MY PATCH AND TEST COMPLIATION AS WELL AS SUGGEST ALTERNATIVES (IF THERE IS AN ISSUE WITH COMPLIATION) IT WOULD BE GREATLY APPRECIATED!!! We have been able to test my patch/fix on different switches without issue - what we are running into currently is not a patch issue more than it is a compliation issue with the patch. You do not need to test Q.SIG - just try the patch from a install/compilation perspective. Thank you. -Keith By: Andrey Kovalenko (akovalen) 2007-01-11 15:06:31.000-0600 Keith, Happy New Year! I incorporated the variable message length per your advise ( I am attaching the relavant change). It works for me now. Can you test it on 8700 when you get a chance. BTW the reason why I can't use the binary libpri you sent me before is because I also need the following change I made in static int rose_address_decode() This helps me get the RDN when digits are in private format: case (ASN1_CONTEXT_SPECIFIC | ASN1_CONSTRUCTOR | ASN1_TAG_5):   /* [5] privatePartyNumber */                        res = rose_public_party_number_decode(pri, call, comp->data, comp->len, value);                        if (res < 0)                                return -1;                        value->npi = PRI_NPI_PRIVATE;                        break; Thanks, Andrey By: Matthew Fredrickson (mattf) 2007-01-22 10:21:57.000-0600 It appears that this patch has been tested quite a bit and works for quite a few people.  Kward, are you ready for me to start reviewing it to be committed? By: Keith Ward (kward) 2007-01-22 11:07:08.000-0600 HI Matt! Yes - I believe the patch ( PathReplacement.SVNr382.patchUPDATE ) is ready for review.  There is a side thread/conversation with Andrey on this list who was able to use the same code/patch functionaly (with some additional changes) for his needs.  The above Patch is for ANFPR Path Replacement only and should work in that regard as per tests from other individuals on this Mantis Bug Report. Please let me know if there are any questions or coding modifications that are required as per the Code Review. Thank you. -Keith By: Keith Ward (kward) 2007-01-22 11:08:50.000-0600 Hi Andrey! I was unable to make the code with your added changes work in my enviroment - but I also do not have that need (so there may be Avaya config issues here as well).  Since the variable message length change is identical in functionality to my original patch I believe both you and I have been successful with THIS BugReport Patch ... ANFPR - Patch Replacement at this point. Thank you for your help in testing! -Keith By: Darren Smith (data23) 2007-01-23 16:52:31.000-0600 Hi kward, > ALL - IF THERE IS SOMEONE WHO COULD DOWNLOAD MY PATCH AND TEST COMPLIATION... I've tried it here on a Fedora Core 6 box, gcc version 4.1.1, after getting trunk 382 via svn version 1.4.2 and am experiencing the same compile-time issues as akovalen is.... Interestingly however, I tried it on a Debian 3.1 box, gcc version 3.1, svn version 1.1.4 and it managed to compile perfectly fine with your patch! Initially i suspected the SVN versions to be returning different source or something, however after tarballing it up from the debian box, it's identical to my fedora copy! Incidentally, patching the latest SVN release (393), it also compiles cleanly on the debian box. Thankfully for me however, after copying the tarball to my slightly aging Fedora Core 1 (gcc 3.3.2-1), live asterisk server, it also compiled fine! This asterisk box is connected internally via a E100P to a BT Nortel Meridian Option 11 pbx, currently via a euroisdn trunk (with the Meridian emulating a local exchange).  Tomorrow evening with the help of BT, we're going to try and migrate it to a qsig trunk, so hopefully i'll be able to test this live against that then. I'll keep you all posted with my progress. Darren P.S Sorry for the lengthy first post :-) By: Andrey Kovalenko (akovalen) 2007-01-24 17:46:59.000-0600 Keith, Thanks for implementing this feature. I hope to see it in the next release of libpri! Andrey By: Andrey Kovalenko (akovalen) 2007-01-24 19:06:34.000-0600 Hi Darren, I'd be very interested to hear about your test results with Nortel Meridian and Asterisk. I did a test with Nortel Succession and Asterisk and outbound calls over QSIG trunks were failing, so I couldn't check if call path replacement works. Thanks, Andrey By: Darren Smith (data23) 2007-01-25 04:22:17.000-0600 Hi Andrey We spent a while last night reconfiguring the link from euroisdn to qsig.  The trunk came back fine and normal calls are working ok. The Path Replacement however isn't working... They've taken a message dump at their end and their 2nd line engineers are going to take a look today. Looking at the logs i see: VERBOSE[10702] logger.c: > Protocol Discriminator: Q.931 (8)  len=41 VERBOSE[10702] logger.c: > Call Ref: len= 2 (reference 6656/0x1A00) (Terminator) VERBOSE[10702] logger.c: > Message type: FACILITY (98) VERBOSE[10702] logger.c: > [1c 22 9f aa 06 80 01 00 82 01 00 8b 01 02 a1 14 02 01 07 02 01 0c 30 0c 0a 01 00 81 00 0a 01 01 02 02 80 06] VERBOSE[10702] logger.c: > Facility (len=36, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8B, 0x01, 0x02, 0xA1, 0x14, 0x02, 0x01, 0x07, 0x02, 0x01, 0x0C, '0', 0x0C, 0x0A, 0x01, 0x00, 0x81, 0x00, 0x0A, 0x01, 0x01, 0x02, 0x02, 0x80, 0x06 ] and then a bit further down... VERBOSE[10702] logger.c: > Protocol Discriminator: Q.931 (8)  len=41 VERBOSE[10702] logger.c: > Call Ref: len= 2 (reference 6/0x6) (Originator) VERBOSE[10702] logger.c: > Message type: FACILITY (98) VERBOSE[10702] logger.c: > [1c 22 9f aa 06 80 01 00 82 01 00 8b 01 02 a1 14 02 01 08 02 01 0c 30 0c 0a 01 01 81 00 0a 01 01 02 02 80 06] VERBOSE[10702] logger.c: > Facility (len=36, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8B, 0x01, 0x02, 0xA1, 0x14, 0x02, 0x01, 0x08, 0x02, 0x01, 0x0C, '0', 0x0C, 0x0A, 0x01, 0x01, 0x81, 0x00, 0x0A, 0x01, 0x01, 0x02, 0x02, 0x80, 0x06 ] Which i'm guessing is correct? However, next i get: VERBOSE[10651] logger.c: < Protocol Discriminator: Q.931 (8)  len=5 VERBOSE[10651] logger.c: < Call Ref: len= 2 (reference 6656/0x1A00) (Originator) VERBOSE[10651] logger.c: < Message type: CONNECT ACKNOWLEDGE (15) VERBOSE[10651] logger.c: < Protocol Discriminator: Q.931 (8)  len=12 VERBOSE[10651] logger.c: < Call Ref: len= 2 (reference 6656/0x1A00) (Originator) VERBOSE[10651] logger.c: < Message type: STATUS (125) VERBOSE[10651] logger.c: < [08 02 81 e4] VERBOSE[10651] logger.c: < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1) VERBOSE[10651] logger.c: <                  Ext: 1  Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ] VERBOSE[10651] logger.c: < [14 01 0a] VERBOSE[10651] logger.c: < Call State (len= 3) [ Ext: 0  Coding: CCITT (ITU) standard (0)  Call state: Active (10) VERBOSE[10651] logger.c: -- Processing IE 8 (cs0, Cause) VERBOSE[10651] logger.c: -- Processing IE 20 (cs0, Call State) VERBOSE[10651] logger.c: < Protocol Discriminator: Q.931 (8)  len=12 VERBOSE[10651] logger.c: < Call Ref: len= 2 (reference 6/0x6) (Terminator) VERBOSE[10651] logger.c: < Message type: STATUS (125) VERBOSE[10651] logger.c: < [08 02 81 e4] VERBOSE[10651] logger.c: < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1) VERBOSE[10651] logger.c: <                  Ext: 1  Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ] So i guess, is why it's failing? Unfortunately i don't understand the q.931 spec enough to work out what message it's asking :) Regards Darren Smith By: Andrey Kovalenko (akovalen) 2007-01-25 14:47:39.000-0600 Darren, Can you please post your complete pri trace from Asterisk.' Also - have you considered using a DMS100 trunk instead of QSIG? I believe Astersisk supports RLT.. Thanks, Andrey By: Darren Smith (data23) 2007-01-25 15:53:05.000-0600 Hi Andrey oops, for some reason i thought uploading files attached them to my post... Serge, feel free to delete em if you like... I was unsure what level of debugging to set, so i enabled two sets. firstly, 'pri debug span 1', 'pri intense debug span 1' and lastly 'pri set debug file /tmp/pridebug.txt' secondly, 'set verbose 15', 'set debug 15' in data23-fulldebug.txt. They also can be found here: http://marge.phat-pipe.net/~data/asterisk/pridebug.txt http://marge.phat-pipe.net/~data/asterisk/fulldebug.txt As for the DMS100 question, I think the BT engineers are a bit unsure over the trunks as well, they phoned me this afternoon after speaking to their 2nd line people and suggested that the asterisk end had to be the master on the trunk, which they'll probably try next week as i'm not that familiar with the trunk commands on the meridian myself. For clarity as well, the logs pertain to the following setup: The Meridian PBX is connected to the BT PSTN network by EuroISDN PRI's. The Asterisk PBX is connected to the Meridian PBX by a single PRI currently configured in qsig/pri_cpe mode. The 'outside' trunk of the meridian is configured to strip of digits of the called number and turn it into an internal extension.... i.e. 01234 666555 becomes 6555. In addition to this, select extensions are configured to pass the call via the Trunk to the asterisk box. In extensions.conf, i simply have: exten => 6555,1,Dial(ZAP/g1/<redirected_no>) Which should pass the call back down the same trunk.  I take it i don't have to answer the call first?   I have also include what gets shown on the normal cli at: http://marge.phat-pipe.net/~data/asterisk/cli.txt Thanks for your help. Darren Smith By: Matthew Fredrickson (mattf) 2007-01-27 14:17:41.000-0600 1.  Don't initialize variables that don't need to be pre-initialized (ex. int res = 0).  Res is set to the return value of asn1_string_encode as it's first use.  Don't reinit res either. 2. Don't declare new variables (buffer2 in anfpr_initiate_transfer and all the variables your declare in your "case SS_ANFPR_PATHREPLACEMENT)) in the middle of the function.  Put it at the top of the function so that you don't break older compilers :-) 3. Is there a particular reason why you are statically "encoding" those buffers rather than wrapping it within the ASN.1 encoding functions (which is much cleaner looking BTW).        buffer2[i++] = (0x0a);        buffer2[i++] = (0x01);        buffer2[i++] = (0x01);        buffer2[i++] = (0x81);        buffer2[i++] = (0x00);        buffer2[i++] = (0x0a);        buffer2[i++] = (0x01);        buffer2[i++] = (0x01); Other than those points, generally speaking it looks good.  I think if you can get them fixed and the patch updated, I will get it committed. By: Keith Ward (kward) 2007-02-02 22:48:41.000-0600 HI Mattf! Will work on your suggestions ... please give me some time. Thank you. -Keith By: Darren Smith (data23) 2007-02-12 16:30:26.000-0600 Hi I've still been tinkering around with this in the background, unfortunately not got much further.  Speaking to BT, they think the Meridian needs to be the slave of the qsig trunk rather than the master.  Changing to pri_net hasn't appeared to have made much of a difference however. The biggest difference was when they changed the link type on their end from QSIG to EGF4 connection.  Most of the unknown messages have gone away now. Our current Meridian config is at: http://marge.phat-pipe.net/~data/asterisk/meridian.txt Other asterisk logs are at: /var/log/asterisk/full: http://marge.phat-pipe.net/~data/asterisk/new-full.txt /var/log/asterisk/debug: http://marge.phat-pipe.net/~data/asterisk/new-debug.txt pri debug: http://marge.phat-pipe.net/~data/asterisk/new-pridebug.txt Has anyone got any thoughts? Best Regards Darren Smith By: Serge Vecher (serge-v) 2007-03-20 15:01:02 kward: any updates here? By: Andrey Kovalenko (akovalen) 2007-04-17 18:00:33 One update is that call path replacement doesn't seem to work on Nortel Meridian/Succession connected over a QSIG trunk to Asterisk. This is consistent with what data23 user had experienced. We have also tried to reverse the scenario and have Nortel Succession PBX issue CPR to Asterisk and it doesn't send any FACILITY messages, so the call stays hairpinned. The issue is most likely on Nortel side, but this document describes QSIG call path replacement between Avaya and Nortel Meridian. Considering that Nortel can do CPR with Avaya and Asterisk can do CPR with Avaya I would expect that Asterisk should be able to do CPR with Nortel: http://www.avaya.com/master-usa/en-us/resource/assets/applicationnotes/qsigtrkcmnortel.pdf By: Darren Smith (data23) 2007-05-16 17:22:00 Hi folks I have our Nortel support company onsite tomorrow to see if they can crack this from the Meridian end... I have this sneaky feeling however, without more work on the patch it may be futile. I'll let you know if i get anywhere, in the meantime, has anyone had any more success? Regards Darren Smith By: Darren Smith (data23) 2007-05-17 18:22:34 Hi Following on from my last post, unfortunately he couldn't identify the exact issue, however has taken full debug-logs from the meridian and is opening a case with Nortel for me. I did find a document the other day (on voipinfo maybe?) that gave a nortel <> asterisk config guide... That was using 5ESS (Lucent?) signalling type at each end.  Haven't tried that myself yet, does anyone know if * supports 5ESS style Path Replacement etc? Best Regards Darren Smith By: Matthew Fredrickson (mattf) 2007-05-31 13:43:26 Since we haven't heard back from the original author, I am going to look through the patch to get it ready for committal.  Is anybody still actively monitoring this bug? By: Darren Smith (data23) 2007-06-02 04:04:10 I am :) Still waiting for our PBX supplier to get feedback from Nortel however :-( - It seems they're not the swiftest bunch on the block so to speak. Regards Darren Smith By: Matthew Fredrickson (mattf) 2007-06-04 18:02:13 Data23, I am still going through the patch and the specs, but I have a suspicion that the reason why it may not be working for you is because you are trying this before the call is in an answered state.  If you put an Answer() as the first thing that occurs when the incoming call arrives, does the patch then work? By: Matthew Fredrickson (mattf) 2007-06-05 08:14:51 It looks like I need to rewrite part of this patch to make it slightly more compatible (many thanks to kward for writing it in the first place though).  I have two questions.  Does anyone who got this working have a trace or can make a trace of this working? and also, If there is someone who has this working, would they mind testing and helping me debug the patch after I get done with it?  FWIW, if kward can get a hold of me, either on IRC or on AIM, that might make it go quicker. By: Darren Smith (data23) 2007-06-05 17:04:47 Hi Matt I've just done another round of testing.  Unfortunately with an Answer() it still doesn't work.  To recap, * box is connected via a E100P to a BT (Nortel) Meridian Option 11.  The link is configured as a QSIG trunk and pri_net signalling. The log files have been captured with: 'pri debug span 1', 'pri intense debug span 1' and 'set verbose 15', 'set debug 15'. The log files are located at: 1. http://marge.phat-pipe.net/~data/asterisk/new/latestpridebug.txt 2. http://marge.phat-pipe.net/~data/asterisk/new/latestdebug.txt 3. http://marge.phat-pipe.net/~data/asterisk/new/latestfull.txt Basically, i dialed from home <Caller_No> via a standard PSTN line into the Meridian via our ISDN30's from BT.  The meridian is configured to route extension 4001 down the internal E1 to Asterisk. Asterisk then answers the call and issues a dial command back down the same E1 Trunk which then sends the call back out via the Meridian/BT to another number. exten => 4001,1,Answer() exten => 4001,2,Dial(ZAP/g1/90<CALLED_NO>) exten => 4001,3,Hangup() Best Regards Darren Smith By: Keith Ward (kward) 2007-06-05 18:33:13 HI mattf! Sorry - do not have time to work this right now - but we have PR in production with this patch to MANY switches (mostly Avaya) at this point with 1000's of hours of good Path Relpacement calls.  Please find pri_debug_prGOOD.txt attached to this bug.  I am available to you (mattf) via email (kward@psshelp.com) and can help test any subsequent "compatibility" changes. By: Matthew Fredrickson (mattf) 2007-06-06 08:30:02 Thanks kward.  I will keep you updated.  You did a good job getting this written.  The patch itself pretty good, it's just I'd like to clean it up a little bit (take the strtoul and sprintf out, as well as take some of the other hardcoded sequences).  If you have a way to verify my changes work as I'm making them, it would make the process bit quicker.  Oh, sorry it's taken so long to get on this, I've been trying to balance my time in quite a few directions lately. By: Matthew Fredrickson (mattf) 2007-06-06 08:36:43 Data23, I'm still getting up to speed on all of this, but it really looks like the other end is not setup as Q.SIG.  I could be wrong, but it seems like there usually are a lot more facility IEs in messages on Q.SIG trunks, and from that setup message, using an ASN.1 object identifier as the operation ID doesn't look like a Q.SIG operation.  All the operation IDs that I have seen for Q.SIG are integers, not objects. By: Matthew Fredrickson (mattf) 2007-06-06 16:49:17 Ok, I just committed a version of this patch to the trunk version of libpri.  Anybody running Asterisk 1.4 can check it out and use it.  It's possible that Asterisk 1.2 works as well, though I'm not sure.  Can I get some people that are testing to try it out? By: Matthew Fredrickson (mattf) 2007-06-06 16:51:19 Oh, by the way, it's in rev 422 of libpri-trunk. :-) By: Matthew Fredrickson (mattf) 2007-06-06 17:17:16 I just uploaded the latest diff.  It is anfpr_rev422trunk.diff, for those of you who would rather patch libpri. By: Darren Smith (data23) 2007-06-08 11:57:17 Hi I'm on holiday now for a week, so won't be able to get the Meridian box looked at until i get back.   I can however say, that i've compiled your new patch against my old libpri trunk / asterisk 1.2 box and restarted and it hasn't broken anything - I can still make/receive calls :) I think you are right however about the setup not being properly QSIG however.... Regards Darren Smith By: Matthew Fredrickson (mattf) 2007-06-21 14:04:50 Applied to trunk.  No more feedback so closing.  Reopen if you want to report feedback.