[asterisk-dev] Problem implementing call redirection on Zap channels
Johann Hanne
jhml at gmx.net
Mon Oct 2 03:35:34 MST 2006
Hi everybody,
I'm currently trying to implement call redirection on Zap channels (1.2 trunk). I.e. our main Avaya/Tenovis pbx which is connected to asterisk via QSIG does not handle redirects itself but only informs Asterisk this way:
---
> Message type: SETUP (5)
< Message type: CALL PROCEEDING (2)
< Message type: FACILITY (98)
< [1c 66 91 aa 06 80 01 00 82 01 00 8b 01 02 a1 58 02 02 05 e1 06 04 2b 0c 09 13 30 4c 0a 01 01 30 06 80 04 34 39 39 30 02 01 01 40 09 04 03 80 90 a3 7d 02 91 81 a1 08 a0 06 80 04 31 33 31 33 82 01 02 a4 0b a0 09 80 04 38 34 30 39 0a 01 01 a7 17 04 12 45 44 56 20 48 6f 74 6c 69 6e 65 20 20 20 20 20 20 20 02 01 01]
< Facility (len=104, codeset=0) [ 0x91, 0xaa, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8b, 0x01, 0x02, 0xa1, 'X', 0x02, 0x02, 0x05, 0xe1, 0x06, 0x04, 0x2b, 0x0c, 0x09, 0x13, '0L', 0x0a, 0x01, 0x01, '0', 0x06, 0x80, 0x04, '4990', 0x02, 0x01, 0x01, 0x40, 0x09, 0x04, 0x03, 0x80, 0x90, 0xa3, 0x7d, 0x02, 0x91, 0x81, 0xa1, 0x08, 0xa0, 0x06, 0x80, 0x04, '1313', 0x82, 0x01, 0x02, 0xa4, 0x0b, 0xa0, 0x09, 0x80, 0x04, '8409', 0x0a, 0x01, 0x01, 0xa7, 0x17, 0x04, 0x12, 'EDV', 0x20, 'Hotline', 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x02, 0x01, 0x01 ]
-- Processing IE 28 (cs0, Facility)
Handle Q.932 ROSE Invoke component
*** tenovis_redirect found: '4990'
-- Now forwarding SIP/8409-081701a8 to 'SIP/8403' (thanks to Zap/1-1) (1)
> Message type: DISCONNECT (69)
< Message type: RELEASE (77)
> Message type: RELEASE COMPLETE (90)
---
(The Avaya/Tenovis pbx could probably be configured to handle the redirect internally, but this is not what I want because the SIP users should be informed about the redirect.)
I already got pretty far: libpri parses the FACILITY message (this is the "*** tenovis_redirect found: '4990'" debug message) and statically mapping all redirected calls to SIP/8403 (i.e. ignoring the real redirect destination) already works. The code snippet in channels/chan_zap.c in pri_dchannel() looks like this:
---
case PRI_EVENT_FACREDIR:
ast_verbose("*** JH: Facility redirection to '%s'\n", e->facredir.redirectingnum);
chanpos = pri_find_principle(pri, e->facredir.channel);
if (chanpos < 0) {
ast_log(LOG_WARNING, "Facility redirection requested on unconfigured channel %d/%d span %d\n",
PRI_SPAN(e->facredir.channel), PRI_CHANNEL(e->facredir.channel), pri->span);
chanpos = -1;
}
if (chanpos > -1) {
chanpos = pri_fixup_principle(pri, chanpos, e->facredir.call);
if (chanpos < 0) {
ast_log(LOG_WARNING, "Facility redirection requested on channel %d/%d not in use on span %d\n",
PRI_SPAN(e->facredir.channel), PRI_CHANNEL(e->facredir.channel), pri->span);
chanpos = -1;
} else {
ast_mutex_lock(&pri->pvts[chanpos]->lock);
// put in the real redirect target (does NOT work):
snprintf(pri->pvts[chanpos]->owner->call_forward, sizeof(pri->pvts[chanpos]->owner->call_forward),
"Zap/g1/%s", e->facredir.redirectingnum);
// dummy redirect to SIP/8403 (works):
//ast_copy_string(pri->pvts[chanpos]->owner->call_forward, "SIP/8403",
sizeof(pri->pvts[chanpos]->owner->call_forward));
ast_mutex_unlock(&pri->pvts[chanpos]->lock);
}
}
break;
---
However, when I activate the redirect to the real target, the QSIG communication breaks:
---
> Message type: SETUP (5)
< Message type: CALL PROCEEDING (2)
< Message type: FACILITY (98)
< [1c 66 91 aa 06 80 01 00 82 01 00 8b 01 02 a1 58 02 02 05 e6 06 04 2b 0c 09 13 30 4c 0a 01 01 30 06 80 04 34 39 39 30 02 01 01 40 09 04 03 80 90 a3 7d 02 91 81 a1 08 a0 06 80 04 31 33 31 33 82 01 02 a4 0b a0 09 80 04 38 34 30 39 0a 01 01 a7 17 04 12 45 44 56 20 48 6f 74 6c 69 6e 65 20 20 20 20 20 20 20 02 01 01]
< Facility (len=104, codeset=0) [ 0x91, 0xaa, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8b, 0x01, 0x02, 0xa1, 'X', 0x02, 0x02, 0x05, 0xe6, 0x06, 0x04, 0x2b, 0x0c, 0x09, 0x13, '0L', 0x0a, 0x01, 0x01, '0', 0x06, 0x80, 0x04, '4990', 0x02, 0x01, 0x01, 0x40, 0x09, 0x04, 0x03, 0x80, 0x90, 0xa3, 0x7d, 0x02, 0x91, 0x81, 0xa1, 0x08, 0xa0, 0x06, 0x80, 0x04, '1313', 0x82, 0x01, 0x02, 0xa4, 0x0b, 0xa0, 0x09, 0x80, 0x04, '8409', 0x0a, 0x01, 0x01, 0xa7, 0x17, 0x04, 0x12, 'EDV', 0x20, 'Hotline', 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x02, 0x01, 0x01 ]
*** tenovis_redirect found: '4990'
*** JH: Facility redirection to '4990'
-- Now forwarding SIP/8409-08172df0 to 'Zap/g1/4990' (thanks to Zap/1-1) (1)
-- Making new call for cr 32771
-- Requested transfer capability: 0x00 - SPEECH
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0)
> Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
> Ext: 1 User information layer 1: A-Law (35)
> [18 03 a9 83 82]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 2 ]
> [6c 06 49 81 38 34 30 39]
> Calling Number (len= 8) [ Ext: 0 TON: Subscriber Number (4) NPI: Private Numbering Plan (9)
> Presentation: Presentation permitted, user number passed network screening (1) '8409' ]
> [70 04 c9 5a 61 70]
> Called Number (len= 6) [ Ext: 1 TON: Subscriber Number (4) NPI: Private Numbering Plan (9) 'Zap' ]
> [74 07 49 01 8f 31 33 31 33]
> Redirecting Number (len= 9) [ Ext: 0 TON: Subscriber Number (4) NPI: Private Numbering Plan (9)
> Ext: 0 Presentation: Presentation permitted, user number passed network screening (1)
> Ext: 1 Reason: Forwarded unconditionally (15) '1313' ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Outgoing call Proceeding, peerstate Incoming Call Proceeding
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Unknown (16), class = Normal Event (1) ]
-- Hungup 'Zap/1-1'
< Message type: RELEASE COMPLETE (90)
< Message type: RELEASE (77)
> Message type: RELEASE COMPLETE (90)
---
If I interpret the debug out correctly, Asterisk tries to reuse the PRI channel and thus the communcation gets f*cked up. I however didn't find a sane way to disconnect the old PRI connection before establishing the new one. Can somebody give me a hint where to go from here? I'm a little lost... Thanks!
Cheers, Johann
More information about the asterisk-dev
mailing list