External callerid issues using Q931 against Toshiba Strata

Home » Asterisk Users » External callerid issues using Q931 against Toshiba Strata
Asterisk Users 5 Comments

Hi Guys,

I currently have an Asterisk 1.6.2.18 server running a patched (see
below) libpri 1.4.10.2 connected to a Toshiba Strata CTX670. All
external calls come in via the Strata and then are routed to the
Asterisk server over a single PRI link using Q931. This setup is
working and has been working for some time (with various earlier
versions of Asterisk) and with a patch (read hack) to libpri I’ve
managed to successfully pass through the numerical portion of the
callerid from the Strata.

I would like to upgrade to Asterisk 1.8 or 10 and use libpri 1.4.12
but am having difficulties picking up the callerid from the Strata and
due to significant changes in libpri my patch no longer applies.

Below is a pri intense debug capturing the Strata sending through the
callerid with libpri upgraded to 1.4.12 (running Dahdi 2.4.1). Libpri
obviously receives the callerid information, but I am unsure of how to
actually access it in Asterisk. I expect that if the callerid
information is properly acquired and recognized in libpri it would
simply be accessible in Asterisk in the ‘CALLERID(all)’ variable, but
it is always empty. Internal calls from an extension on the Strata to
an Asterisk extension show the callerid as expected.

Does anyone have any tips on how to get Asterisk to use the callerid
passed through by the Strata?

Thanks!

Justin

chan_dahdi.conf (group 2 is used outgoing only):
[trunkgroups]

[channels]
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
transfer=yes
cancallforward=yes
echocancel=128
echocancelwhenbridged=yes
echotraining=no
rxgain=0.0
txgain=-10
context=from-toshiba
overlapdial=no
facilityenable=yes
switchtype=qsig
signalling=pri_net
group=1
channel => 1-23
switchtype=national
signalling=pri_cpe
group=2
channel => 25-47

pri intense debug:
< TEI: 0 State 7(Multi-frame established)
< V(A)=31, V(S)=31, V(R)=42
< K=7, RC=0, l3_initiated=0, reject_except=0, ack_pend=0
< T200_id=0, N200=3, T203_id=8192
< [ 00 01 54 3e 08 02 01 b3 62 1c 66 9f aa 06 80 01 00 82 01 00 a1 31
02 02 01 3a 02 01 0c 30 28 0a 01 01 a0 0f 80 0a 35 35 35 35 35 35 31
36 33 31 0a 01 00 80 0f 41 41 41 20 49 54 2d 44 41 54 41 00 00 00 00
0a 01 01 a1 28 02 02 01 3b 02 01 55 30 1f 86 01 00 a7 1a 06 0a 31 33
31 32 32 31 35 35 35 35 30 0c 81 01 07 8c 04 39 34 31 31 95 01 00 ]
< Informational frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< N(S): 042 0: 0
< N(R): 031 P: 0
< 109 bytes of data
< Protocol Discriminator: Q.931 (8) len=109
< TEI=0 Call Ref: len= 2 (reference 435/0x1B3) (Sent from originator)
< Message Type: FACILITY (98)
< [1c 66 9f aa 06 80 01 00 82 01 00 a1 31 02 02 01 3a 02 01 0c 30 28
0a 01 01 a0 0f 80 0a 35 35 35 35 35 35 31 36 33 31 0a 01 00 80 0f 41
41 41 20 49 54 2d 44 41 54 41 00 00 00 00 0a 01 01 a1 28 02 02 01 3b
02 01 55 30 1f 86 01 00 a7 1a 06 0a 31 33 31 32 32 31 35 35 35 35 30
0c 81 01 07 8c 04 39 34 31 31 95 01 00]
< Facility (len=104, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00,
0x82, 0x01, 0x00, 0xA1, ‘1’, 0x02, 0x02, 0x01, ‘:’, 0x02, 0x01, 0x0C,
‘0(‘, 0x0A, 0x01, 0x01, 0xA0, 0x0F, 0x80, 0x0A, ‘5555551631’, 0x0A,
0x01, 0x00, 0x80, 0x0F, ‘AAA IT-DATA’, 0x00, 0x00, 0x00, 0x00, 0x0A,
0x01, 0x01, 0xA1, ‘(‘, 0x02, 0x02, 0x01, ‘;’, 0x02, 0x01, ‘U0’, 0x1F,
0x86, 0x01, 0x00, 0xA7, 0x1A, 0x06, 0x0A, ‘13122155550’, 0x0C, 0x81,
0x01, 0x07, 0x8C, 0x04, ‘9411’, 0x95, 0x01, 0x00 ]

5 thoughts on - External callerid issues using Q931 against Toshiba Strata

  • Is the information you are interested in in the ROSE_QSIG_CallTransferComplete
    section of the FACILITY or the ROSE_Unknown section? Both contain numbers.

    If it is the ROSE_QSIG_CallTransferComplete section then I need to see
    more messages to know what is happening in the call. I also do not need to
    see intense output because your issue is in the Q.931 level and not the Q.921
    level.

    Richard

  • Resending below (guess the original attachment was too big).

    I’m looking for the information contained in the
    ROSE_QSIG_CallTransferComplete section. I have attached a complete log
    of the call (with intense debug on unfortunately). An additional note:

    1. The Strata system initially sends through a virtual internal
    extension number (‘1607’ in the log) as the originating number. In the
    dial plan I immediately play back a ringing sound to the Strata which
    causes it to then send through the real external callerid information.
    As such my original email was a bit off the mark, I get a blank
    callerid name and the callerid number is the virtual internal
    extension. Apologies for the confusion.

    Thanks again,

    Justin

    default iconpri_full.tar.gz

  • The ROSE_QSIG_CallTransferComplete message has the callStatus set to 1
    which indicates that the peer is ringing. Libpri is waiting for a
    ROSE_QSIG_CallTransferActive to post the connected line information
    because the ROSE_QSIG_CallTransferComplete connected line information
    may not have the correct presentation value available. I suspect
    that the Strata is sending the wrong value for that parameter because
    it seems to be telling Asterisk that it is ringing instead.

    You could try this hack:

    Index: pri_facility.c
    ===================================================================

  • I can confirm that the provided patch allows Asterisk to pickup both
    the external callerid name and number.

    Going forward is there a clean way to handle this issue, or can it
    really only live as a hack?

    Thank you very much for the quick replies and spot on help!

    Justin

  • It will have to stay a hack because I think the Strata is sending the
    wrong value for the callStatus parameter. Asterisk already knows that
    it is ringing so why is the Strata telling Asterisk that it is ringing.
    The callStatus parameter is supposed to tell Asterisk the call state
    of the connected peer so it can expect a future message when the peer
    actually answers.

    Richard