|Summary:||ASTERISK-04580: Problem interpreting FACILITY during setup from HiPath 4k|
|Reporter:||Markus Barckmann (worta)||Labels:|
|Date Opened:||2005-07-13 10:43:23||Date Closed:||2011-06-07 14:03:16|
|Description:||When using Asterisk connected to an Siemens HiPath 4k (pri_net; E1; QSIG) the FAC message carrying die Calling Party Name is discarded. |
Debug: "Don't know what to do if second ROSE component is of type 0x6"
****** ADDITIONAL INFORMATION ******
"Offending" Message example:
1c 2f 91 aa 06 80 01 00 82
01 00 8b 01 00 a1 21 02 02
a2 70 06 04 2b 0c 09 00 a1
15 04 10 42 41 52 43 4b 4d
41 4e 4e 20 4d 41 52 4b 55
53 02 01 01
|Comments:||By: Matthew Fredrickson (mattf) 2005-07-13 10:49:57|
Do not report bugs agains CVS-HEAD without updating to latest CVS-HEAD. ESPECIALLY in regards to facility messages. What happens when you use latest head?
By: Markus Barckmann (worta) 2005-07-13 11:17:23
Sorry, already using latest CVS-HEAD.
I was just to stupid realizing the current date. :)
By: Matthew Fredrickson (mattf) 2005-07-13 15:16:06
Whatever message that the switch is sending, it's not one that libpri supports. I can't even eyeball this thing. I see where the name is probably encoded, but the rest of the message doesn't make a lot of sense. No operation ID, which should come after the invoke ID is specified in a way that I understand.
By: Markus Barckmann (worta) 2005-07-14 04:39:34
I've added a dirty hack to pri_facility.c stating:
#define HP_CNID_CALLINGNAME 722209024
pri_message(pri, " Handle Name display operation\n");
memcpy(call->callername, comp->data+2, comp->len-5);
call->callername[comp->len] = 0;
Additional i've disabled the CHECK_COMPONENT lines. - Now display names are correctly interpreted.
I'll investigate together with the Siemens developers where these (bogus?) operation ID's are coming from. And post an explaination and/or patch.
By: dbruce (dbruce) 2005-07-15 03:49:59
It looks like the Siemens either doesn't follow the standards for PRI/EuroISDN Components, or has some very strange provider specific inplimentations. The Protocol is followed though.
This is how the provided FACILITY IE should be interpreted:
91 suplimentary service (ROSE)
aa unknown invoke component (unknown PDUs should be discarded)
06 length: 6 bytes (this PDU seems to have a provider specific usage)
80 01 00 82 01 00
01 length: 1 byte
00 Discard unknown PDUs
a1 operation: Invoke
21 length: 33 bytes
02 type: integer
02 length: 2 bytes
a2 70 value: 41584 - Invoke ID
06 Type: Object ID
04 length : 4
2b 0c 09 00 ( = 220.127.116.11.0 - appears to be provider specific)
(object IDs sould be 5 or 7 bytes)
a1 Operation: Invoke
15 length: 21 bytes
04 type: octet string
10 length: 16 bytes
42 41 52 43 4b 4d 41 4e 4e 20 4d 41 52 4b 55 53 (CBSDLNBOO NBSLVT) caller name?
02 type: integer
01 length: 1
By: wsandiford (wsandiford) 2005-07-16 07:52:42
Just as a point of interest, I don't think this message is a Siemens related issue as I also get the same warning every time a call is received on my PRI. My PRI is NI2 from Sprint Canada. As far as I am aware, Sprint Canada is using a 5ESS.
By: Markus Barckmann (worta) 2005-07-18 09:53:28
I've just got an answer from the Siemens development
The Object ID 18.104.22.168.0 is constructed (ECMA-143) as follows:
iso (1) => identified-organization (3) => icd-ecma (12) => private-isdn-signalling-domain (9) => calling-name (0)
I'm unable to tell, why there are 5 or 7 Bytes expected.
During my tests i've discovered another strange thing: If I try to perform an outbound call Asterisk => Siemens and facility sending is enabled the Siemens HiPath PBX answers instantly with RELEASE. Tracing this issue we found the HiPath whimpering something about a "mandatory message element missing".
This leads to the conclusion that there maybe a general imparity in the interpretation of the ecma papers.
I'll do another tracing session tomorrow and connect a Cisco device <=> Asterisk. :)
By: Matthew Fredrickson (mattf) 2005-07-19 17:32:37
I'm changing this to a feature request since this message (or this format of message) is not intended to work in libpri. If someone would like to write a patch to interpret it, then I will certainly be open to the possiblity of accepting it back into libpri in case someone else sees callername placed in this particular format.
By: Matthew Fredrickson (mattf) 2005-07-26 17:38:46
Anybody going to tackle this problem?
By: Matthew Fredrickson (mattf) 2005-08-05 09:32:35