[Home]

Summary:ASTERISK-03476: [patch] libpri features - 2B channel transfer, MWI, callername over facility
Reporter:Matthew Fredrickson (mattf)Labels:
Date Opened:2005-02-10 16:56:35.000-0600Date Closed:2005-03-15 09:41:38.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap-2bct.diff
( 1) debug-pri-name-display.txt
( 2) debug-pri-name-display2.txt
( 3) libpri-matt5.diff
( 4) libpri-matt-experimentalcpecallername.diff
( 5) libpri-matt-experimentalcpecallername2.diff
( 6) pri-fix.diff
Description:This is basically all of the changes that I have been doing to libpri for the past few months.  Included features are callername over facility, two b channel transfer.  If some people can take a look at this and test it that would be great.

****** ADDITIONAL INFORMATION ******

Disclaimed :-)
Comments:By: Matthew Fredrickson (mattf) 2005-02-11 09:11:18.000-0600

Added patch for asterisk to support 2 B-Channel Transfer.  Need to have a 5ESS or compatible switch for it to work.

By: lesnet (lesnet) 2005-02-11 15:45:40.000-0600

Reminder sent to mattf

Matt, please contact me about this patch voip@les.net

By: Tilghman Lesher (tilghman) 2005-02-11 17:23:07.000-0600

Callername does not seem to work.

By: Matthew Fredrickson (mattf) 2005-02-11 18:00:31.000-0600

Ok, try the new version that I just uploaded.  I had forgotten to have it send the callername facility message.

By: Matthew Fredrickson (mattf) 2005-02-11 18:08:15.000-0600

Sorry, had a little buglet in that patch and reloaded it up.  Try again.

By: Paul Cadach (pcadach) 2005-02-12 03:33:04.000-0600

Is this part is required
   for (istr = 0; istr < destlen; istr++)
       buffer[i+istr] |= 0x30; /* Have to or each digit with 0x30 to encode correctly */
when you have c->called string with numbers only?

Also, Operation ID object identifier encoding at add_callername_facility_ies() looks like
   /* Operation ID */
   buffer[i++] = ASN1_INTEGER;
   buffer[i++] = 0x01;
   buffer[i++] = ASN1_OBJECTIDENTIFIER;

   buffer[i++] = 0x07; /* Length */
   buffer[i++] = 0x2a; /* informationFollowing 42 */
   buffer[i++] = 0x86;
   buffer[i++] = 0x48;
   buffer[i++] = 0xce;
   buffer[i++] = 0x15;
   buffer[i++] = 0x00;
   buffer[i++] = 0x04;

while at eect_initiate_transfer() like
   buffer[i++] = ASN1_OBJECTIDENTIFIER;
   buffer[i++] = 0x07;
   buffer[i++] = 0x2A;
   buffer[i++] = 0x86;
   buffer[i++] = 0x48;
   buffer[i++] = 0xCE;
   buffer[i++] = 0x15;
   buffer[i++] = 0x00;
   buffer[i++] = 0x08;


Also, IMHO ASN1_SEQUENCE value is wrong because sequence is always compound component (i.e. embedds other components) so must be ORed with 0x20 => ASN1_SEQUENCE code must be 0x30 instead of 0x10. 0x10 is something else (I'm about next part
   buffer[i++] = ASN1_SEQUENCE;
   buffer[i++] = 0x04;
   buffer[i++] = 0x02;
   buffer[i++] = ((call_reference>>8)&0xFF);
   buffer[i++] = (call_reference&0xFF);
). Also, in this place you specifies component length equal to 4 bytes while you adds 3 bytes only (0x02 and two bytes of call reference). Something is wrong IMHO. Or, may be, you lost ASN1_SEQUENCE's length byte.

By: Matthew Fredrickson (mattf) 2005-02-14 18:51:59.000-0600

Fixed a little bug in the ASN.1 encoding on the 2 BChannel transfer stuff.  Also OR'd the ASN1_SEQUENCE with 0x30 to encode it correctly.

By: Paul Cadach (pcadach) 2005-02-16 12:35:41.000-0600

Latest Matt's patch is fully "macroished", transmisson code fixed, PRI event names added, testprilib modified to handle new code.

Topic to discuss - when and how to call q931_facility if something exists to be sent out with Q931_FACILITY message.

By: Matthew Fredrickson (mattf) 2005-02-17 18:22:31.000-0600

What is the "scope" of a FACILITY message?  Is it any time after the SETUP is sent?  If so, we might do some trickery within the queue function to automatically do a send_message() of type Q931_FACILITY if the call has been established already and if not, make some sort of flag variable like needtotxfacility in q931_call that would be checked upon arrival of the next message after SETUP.

By: Trevor Peirce (trev) 2005-02-18 14:47:48.000-0600

Okay so what does this patch get applied to, or is it already in CVS?

By: Matthew Fredrickson (mattf) 2005-02-18 14:54:52.000-0600

It's a patch against CVS-head.

By: Matthew Fredrickson (mattf) 2005-02-18 15:04:21.000-0600

Uploaded new version of patch (includes all previous changes and bugfixes)

By: Trevor Peirce (trev) 2005-02-18 15:05:24.000-0600

Aha, patch against libpri not libpri-matt (I guess you already applied it there).

My telco swears up one wall and down the other that their switch is set up to correctly allow outgoing name support, and they are blaming it on my end (because they've never heard of asterisk).  I'm not sure what these errors mean, but I am assuming it relates to the name since I don't see it if I do not send a name.

See debug-pri-name-display.txt

If this is unrelated just let me know and I'll delete my bugnotes. Thanks!

By: Matthew Fredrickson (mattf) 2005-02-18 15:09:20.000-0600

Ooh,  you're trying it from the CPE side.  I'm not sure if CPE side is the same as doing it NET side.  I think I have it right for doing NET side NI2, but I have doubts as to whether or not we do it correctly for sending from CPE.

By: Trevor Peirce (trev) 2005-02-18 15:10:58.000-0600

Well... I'll gladly play guinnea pig if you have any ideas... :)

By: Matthew Fredrickson (mattf) 2005-02-18 15:31:19.000-0600

I just uploaded a version that sends callername information regardless if your NET or CPE side.  Try that out and see if you get anywhere.

By: Trevor Peirce (trev) 2005-02-18 15:38:32.000-0600

Nada... though I got the same output as earlier... from what I gather the name was being sent then as well.

By: Matthew Fredrickson (mattf) 2005-02-18 15:58:36.000-0600

Found and fixed a bug in the send code.  Try again, and if you can post a dump that would help too.

By: Trevor Peirce (trev) 2005-02-18 16:09:10.000-0600

Uploaded #2

By: Matthew Fredrickson (mattf) 2005-02-18 16:20:29.000-0600

Hrm... well, it looks like it won't work then.  I had hoped.  Maybe I'll find a copy of GR-1367 one of these days so I can find out how to do it the "right" way.

By: Paul Cadach (pcadach) 2005-02-18 16:26:00.000-0600

Remote site just rejects invoke component for name display supplementary service. Reject code = 1. Also, there is invalid invoke_id encoding in reject component (0x02 0x02 0x01 0x00, i.e. 0x100 while at transmission it was 0x02 0x01 0x01, i.e. 0x0001).

By: Trevor Peirce (trev) 2005-02-19 17:24:53.000-0600

Any way I'd be able to gather the information you need?  I was looking on Telcordia's site and they want $672 for that document... that's quite a way outside what I consider acceptable.

By: Matthew Fredrickson (mattf) 2005-02-19 18:36:11.000-0600

Post a dump that has a working callerid name transfer from CPE to NET (with hex values for messages and IEs, etc) and I think that I could do it.

By: Paul Cadach (pcadach) 2005-02-19 20:03:14.000-0600

Addition to Matthew's note: You could ask your telco for call trace with working CPE->NET caller name in any form they can do.

By: bporch (bporch) 2005-02-21 11:48:31.000-0600

I have applied this .diff but could someone please give me an example of how to initiate the 2BCT?  I assume this is done from the dialplan.

By: Matthew Fredrickson (mattf) 2005-02-21 15:16:24.000-0600

It is automatically done.  It works on 5ESS switchtypes from the CPE side.  If it works, it will look (from the asterisk side) like the call was dropped for both legs.

By: bporch (bporch) 2005-02-21 17:14:47.000-0600

I'm thinking that for 2BCT to be added to asterisk-proper there would need to be an option to explicity choose to do this.  I'm sure there are reasons why you might want to keep a bridged call on your switch.  For example if you wanted CDR records for the legs or if you wanted to be able to forcibly terminate the call at some point.  

I would like to see this implemented as a dialplan command to mark the leg of the call as being eligible for 2BCT - then if * sees two legs of a bridged call marked eligible on the same PRI it can push it up.

By: Matthew Fredrickson (mattf) 2005-02-21 18:01:50.000-0600

Hrm... what about just adding a flag in the zapata.conf something to the affect of can2bchaneltransfer=yes?

I'm kind of hesitant about implementing such a channel specific application for the dialplan.  I don't know if that would be the best way to go about doing this.

By: Matthew Fredrickson (mattf) 2005-03-02 09:59:14.000-0600

Committed

By: Matthew Fredrickson (mattf) 2005-03-02 10:12:40.000-0600

Committed.

By: Russell Bryant (russell) 2005-03-02 11:17:36.000-0600

mattf is awesome

By: Russell Bryant (russell) 2005-03-10 02:09:17.000-0600

reopening for PCadach

By: Paul Cadach (pcadach) 2005-03-10 02:13:52.000-0600

pri-fix.diff (disclaimed, of course):
- some mistakes on pri_facility.c fixed (access freed memory for "next" pointer, misplaced debugging test);
- testprilib.c is enhanced to handle full simple call (SETUP-PROCEEDING-ALERTING-CONNECT...-DISCONNECT-RELEASE-RELEASE COMPLETE).

By: Donny Kavanagh (donnyk) 2005-03-10 02:22:17.000-0600

Just to confirm, to use this functionality, switchtype must be set to 5ess, and we should be using which Dial to bridge the calls (and then pass them off) or Transfer?

By: Paul Cadach (pcadach) 2005-03-10 02:31:49.000-0600

Just set switchtype to 5ess and regular Dial() on the same PRI span should invoke 2BCT. Please note of preliminary support for 2BCT!

By: Donny Kavanagh (donnyk) 2005-03-10 02:58:13.000-0600

On a somewhat technical note, is it possible to do this type of transfer with any other switch types?  Aka is 5ess being the only type to be able to do 2BCT a limitation of pri, or just the only support thats been developed in libpri/* to date.

By: Paul Cadach (pcadach) 2005-03-10 03:37:46.000-0600

2BCT service just exists for Lucent 5ESS switches. Support of such services on other switches/PRI variant currently isn't known. Possible Q.SIG have something like Lucent's 2BCT but needs to be verified.

By: petersv (petersv) 2005-03-10 03:40:58.000-0600

Is 2BCT functionally different from CD (Call Deflection) on unanswered calls or ECT (Explicit Call Transfer) on answered calls?

By: Paul Cadach (pcadach) 2005-03-10 03:52:36.000-0600

Looks like the same. I don't know well about relation between fuctionality of 2BCT, CD and ECT but last two ones isn't supported in the current design. Also, as for 2BCT, CD and ECT isn't supported by all switches and mostly defined for Q.SIG only. US/Canada PRI's national standards isn't publicly available and costs many $$$, so I don't think there is a chance to get implemented within free libpri and Asterisk until someone is sponsored it (supplementary service documentation from TelCordia) or published its documentation.

By: petersv (petersv) 2005-03-10 04:17:02.000-0600

Both of these are EuroISDN standards, I think. ECT is a subscription option from our pstn supplier and CD is enabled by default.

The standrads for both options are available for free from Etsi. A good reference for most supplementary services is

http://www.telia.se/upload/upload_doc/ch5revf.doc

This is the Implementors Note from the Swedish incumbent Telia. It has references to the corresponding standards for each service. I find it easier to read than the corresponding document from other operators such as Deutsche Telecom.

chan_capi already supports CD / ECT.

By: Matthew Fredrickson (mattf) 2005-03-10 13:11:11.000-0600

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 ;-)

By: Matthew Fredrickson (mattf) 2005-03-10 14:41:25.000-0600

Ok, committed the buglette fixes from PCadach

By: petersv (petersv) 2005-03-10 15:16:33.000-0600

When can you use 2BCT (during call setup, after sending connect or both)? I think ECT and CD are limited to one or the other. Both are probably rose invokes.

Where is the decision to invoke the 2BCT make? In the Dial application or by a lower layer? Can other handoff technologies hook in at the same place?

CD/ECT allow extra information to be sent (reason for deflection etc). The information could be passed from the dialplan in a channel variable.

By: Donny Kavanagh (donnyk) 2005-03-10 15:34:22.000-0600

Shoudn't we also be able to not use 2BCT if it is supported, there may be reasons where we want to keep the calls bridged through asterisk.  Perhaps we need an option in Dial(..) to enable this functionality if it is supported.  Or to disable it, which ever approach you feel is correct.

By: Matthew Fredrickson (mattf) 2005-03-11 01:45:03.000-0600

You can use 2BCT any time after the call SETUP message is sent (including during the PROCEEDING state, i.e. ringing).  The decision to invoke a 2BCT is done in chan_zap.c, and is done in the existing native bridge mechanism in the ast_channel_bridge (if I remember correctly) function.  Other technologies such as chan_iax.c and chan_sip.c for reinvites and the like.

CD/ECT Transfer reason is already passed to the Dialplan in the ${PRIREDIRECTREASON} variable.  See chan_zap.c for more info on it.

I just changed it so that the "transfer" keyword in zapata.conf enables/disables 2BCT on channels.

By: Matthew Fredrickson (mattf) 2005-03-14 14:23:27.000-0600

Fixed.