[Home]

Summary:ASTERISK-04580: Problem interpreting FACILITY during setup from HiPath 4k
Reporter:Markus Barckmann (worta)Labels:
Date Opened:2005-07-13 10:43:23Date Closed:2011-06-07 14:03:16
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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
case HP_CNID_CALLINGNAME:
        pri_message(pri, "  Handle Name display operation\n");
        memcpy(call->callername, comp->data+2, comp->len-5);
        call->callername[comp->len] = 0;
        break;

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

8b Interpretation
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 ( = 1.3.12.9.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
01
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

[cut]
The Object ID 1.3.12.9.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.
[/cut]

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

No feedback