asterisk 1.8 PRI random call drop issue

Home » Asterisk Users » asterisk 1.8 PRI random call drop issue
Asterisk Users 1 Comment

Hi,

We having some PRI call drop issue on asterisk 1.8.x but we had no issue never ever on asterisk 1.2. Anybody else having this issue ?

-S

One thought on - asterisk 1.8 PRI random call drop issue

  • Sure,

    Start call

    [Jun 10 10:01:17] VERBOSE[27776] netsock2.c: == Using SIP RTP CoS mark 5
    [Jun 10 10:01:17] VERBOSE[7269] pbx.c: — Executing [8004815122@from-sip:1] Dial(“SIP/7081-000005ed”, “DAHDI/g1/18004815122”) in new stack
    [Jun 10 10:01:17] DEBUG[7269] sig_pri.c: sig_pri_request 5
    [Jun 10 10:01:17] DEBUG[7269] sig_pri.c: CALLER NAME: Pascal Honscher NUM: 7081
    [Jun 10 10:01:17] VERBOSE[7269] sig_pri.c: — Requested transfer capability: 0x00 – SPEECH
    [Jun 10 10:01:17] VERBOSE[7269] app_dial.c: — Called DAHDI/g1/18004815122
    [Jun 10 10:01:17] VERBOSE[7269] app_dial.c: — DAHDI/i1/18004815122-1db is proceeding passing it to SIP/7081-000005ed
    [Jun 10 10:01:17] DTMF[7267] channel.c: DTMF begin ‘1’ received on SIP/7134-000005eb
    [Jun 10 10:01:17] DTMF[7267] channel.c: DTMF begin ignored ‘1’ on SIP/7134-000005eb
    [Jun 10 10:01:17] DTMF[7267] channel.c: DTMF end ‘1’ received on SIP/7134-000005eb, duration 130 ms
    [Jun 10 10:01:17] DTMF[7267] channel.c: DTMF end passthrough ‘1’ on SIP/7134-000005eb
    [Jun 10 10:01:17] VERBOSE[7267] file.c: — Playing ‘vm-first.ulaw’ (language ‘en’)
    [Jun 10 10:01:18] VERBOSE[7267] config.c: == Parsing ‘/var/spool/asterisk/voicemail/default/7134/INBOX/msg0000.txt’: [Jun 10 10:01:18] VERBOSE[7267] config.c: == Found
    [Jun 10 10:01:18] VERBOSE[7267] file.c: —
    Playing ‘vm-message.ulaw’ (language ‘en’)
    [Jun 10 10:01:18] VERBOSE[7267] file.c: —
    Playing ‘vm-received.ulaw’ (language ‘en’)
    [Jun 10 10:01:19] VERBOSE[7268] app_dial.c: — DAHDI/i1/18778603058-1da is ringing
    [Jun 10 10:01:19] VERBOSE[7268] app_dial.c: — DAHDI/i1/18778603058-1da is making progress passing it to SIP/7065-000005ec
    [Jun 10 10:01:19] VERBOSE[7268] app_dial.c: — DAHDI/i1/18778603058-1da answered SIP/7065-000005ec
    [Jun 10 10:01:19] DEBUG[7268] channel.c: setting peeraccount to “Sharon Cordesse” for SIP/7065-000005ec from data on channel DAHDI/i1/18778603058-1da
    [Jun 10 10:01:19] VERBOSE[7269] app_dial.c: — DAHDI/i1/18004815122-1db is making progress passing it to SIP/7081-000005ed
    [Jun 10 10:01:19] VERBOSE[7267] file.c: —
    Playing ‘digits/at.ulaw’ (language ‘en’)
    [Jun 10 10:01:20] VERBOSE[7269] app_dial.c: — DAHDI/i1/18004815122-1db answered SIP/7081-000005ed
    [Jun 10 10:01:20] DEBUG[7269] channel.c: setting peeraccount to “Pascal Honscher” for SIP/7081-000005ed from data on channel DAHDI/i1/18004815122-1db

    Hangup and again dial

    [Jun 10 10:01:57] DEBUG[7269] sig_pri.c: sig_pri_hangup 5
    [Jun 10 10:01:57] DEBUG[7269] sig_pri.c: Not yet hungup… Calling hangup once with icause, and clearing call
    [Jun 10 10:01:57] VERBOSE[7269] chan_dahdi.c: — Hungup ‘DAHDI/i1/18004815122-1db’
    [Jun 10 10:01:57] VERBOSE[7269] pbx.c: == Spawn extension (from-sip, 8004815122, 1) exited non-zero on ‘SIP/7081-000005ed’
    [Jun 10 10:02:01] VERBOSE[7224] file.c: — Playing ‘vm-intro.ulaw’ (language ‘en’)
    [Jun 10 10:02:02] VERBOSE[27776] netsock2.c: == Using SIP RTP CoS mark 5
    [Jun 10 10:02:02] VERBOSE[7286] pbx.c: — Executing [7069@from-sip:1] Macro(“SIP/7134-000005f0”, “stdexten,7069,SIP/7069”) in new stack
    [Jun 10 10:02:02] VERBOSE[7286] pbx.c: — Executing [s@macro-stdexten:1] Set(“SIP/7134-000005f0”, “_CALLED_EXT=SIP/7069”) in new stack
    [Jun 10 10:02:02] VERBOSE[7286] pbx.c: — Executing [s@macro-stdexten:2] Dial(“SIP/7134-000005f0”, “SIP/7069&iax2/7069,20,t”) in new stack
    [Jun 10 10:02:02] VERBOSE[7286] netsock2.c: == Using SIP RTP CoS mark 5
    [Jun 10 10:02:02] VERBOSE[7286] app_dial.c: — Called SIP/7069
    [Jun 10 10:02:02] WARNING[7286] app_dial.c: Unable to create channel of type ‘iax2’ (cause 20 – Unknown)
    [Jun 10 10:02:02] VERBOSE[7286] app_dial.c: — SIP/7069-000005f1 is ringing
    [Jun 10 10:02:04] VERBOSE[27776] netsock2.c: == Using SIP RTP CoS mark 5
    [Jun 10 10:02:04] VERBOSE[7287] pbx.c: — Executing [8004815122@from-sip:1] Dial(“SIP/7081-000005f2”, “DAHDI/g1/18004815122”) in new stack
    [Jun 10 10:02:04] DEBUG[7287] sig_pri.c: sig_pri_request 5
    [Jun 10 10:02:04] DEBUG[7287] sig_pri.c: CALLER NAME: Pascal Honscher NUM: 7081
    [Jun 10 10:02:04] VERBOSE[7287] sig_pri.c: — Requested transfer capability: 0x00 – SPEECH
    [Jun 10 10:02:04] VERBOSE[7287] app_dial.c: — Called DAHDI/g1/18004815122
    [Jun 10 10:02:04] VERBOSE[7287] app_dial.c: — DAHDI/i1/18004815122-1dc is proceeding passing it to SIP/7081-000005f2
    [Jun 10 10:02:06] VERBOSE[7224] file.c: —
    Playing ‘beep.ulaw’ (language ‘en’)
    [Jun 10 10:02:06] VERBOSE[7287] app_dial.c: — DAHDI/i1/18004815122-1dc is making progress passing it to SIP/7081-000005f2
    [Jun 10 10:02:07] VERBOSE[7224] app_voicemail.c: — Recording the message
    [Jun 10 10:02:07] VERBOSE[7224] app.c: — x=0, open writing: /var/spool/asterisk/voicemail/default/7000/tmp/L7WLl1 format: wav49, 0x2b98578
    [Jun 10 10:02:07] VERBOSE[7224] app.c: — x=1, open writing: /var/spool/asterisk/voicemail/default/7000/tmp/L7WLl1 format: gsm, 0x2c56eb8
    [Jun 10 10:02:07] VERBOSE[7224] app.c: — x=2, open writing: /var/spool/asterisk/voicemail/default/7000/tmp/L7WLl1 format: wav, 0x29e9ae8
    [Jun 10 10:02:07] VERBOSE[7287] app_dial.c: — DAHDI/i1/18004815122-1dc answered SIP/7081-000005f2
    [Jun 10 10:02:07] DEBUG[7287] channel.c: setting peeraccount to “Pascal Honscher” for SIP/7081-000005f2 from data on channel DAHDI/i1/18004815122-1dc

    Hi,

    We having some PRI call drop issue on asterisk 1.8.x but we had no issue never ever on asterisk 1.2. Anybody else having this issue ?

    -S

    What troubleshooting have you already done? Do you have logs? Debug information? What error messages are displaying when the call is dropped? The more information you can provide us, the better we can help you.

    I would suggest as a minimum that you provide us with the CLI output of a complete, dropped call. We can move forward from there.