Summary: | ASTERISK-17025: [patch] Disable connected line updates for dahdi PRI channel | ||||
Reporter: | Michael Smith (asbestoshead) | Labels: | |||
Date Opened: | 2010-11-25 11:04:23.000-0600 | Date Closed: | 2012-03-15 18:29:53 | ||
Priority: | Major | Regression? | No | ||
Status: | Closed/Complete | Components: | Channels/chan_dahdi | ||
Versions: | Frequency of Occurrence | ||||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) asterisk-connected-line-block.patch ( 1) asterisk-connected-line-block-v2.patch | |||
Description: | I need to prevent connected line updates from being sent to a PRI channel. I'm having problems when a call from a PRI is answered by a SIP extension, then transferred (blind or attended) to another SIP extension. One of my PRI providers can't handle the ROSE_ETSI_EctInform APDU and drops the call. Looking through the chan_dahdi and sig_pri code, I don't see any configuration flag to block the updates from going through. I would like to add one. Looking for guidance to add support to block these updates. I'm thinking I could patch ast_channel_connected_line_macro() to check for a variable, CONNECTED_LINE_CALLER_BLOCK or CONNECTED_LINE_CALLEE_BLOCK, and to prevent the call to ast_channel_update_connected_line() if it is set to 1. For completeness I'd also patch ast_channel_redirecting_macro() to check for REDIRECTING_CALLER_BLOCK and REDIRECTING_CALLEE_BLOCK. I'd then just have to add setvar=CONNECTED_LINE_CALLER_BLOCK=1 in my chan_dahdi.conf, and for outbound calls to the PRI I may also have to Set(CONNECTED_LINE_CALLEE_BLOCK=1) in the dialplan. ****** ADDITIONAL INFORMATION ****** Here's what happens when external number 87133306 calls into my PRI, extension 1111 answers, does an attended transfer to 0102, and completes the transfer. The provider eventually hangs up with "Message not compatible with call state (101)". {noformat} channel.c: Released clone lock on 'SIP/1111-00000007<ZOMBIE>' channel.c: Done Masquerading DAHDI/i1/87133306-3 (6) chan_dahdi.c: Requested indication 26 on channel DAHDI/i1/87133306-3 chan_dahdi.c: Requested indication 17 on channel DAHDI/i1/87133306-3 channel.c: Bridge stops because we're zombie or need a soft hangup: c0=SIP/1111-00000007<ZOMBIE>, c1=SIP/1111-00000006, flags: Yes,Yes,No,No channel.c: Bridge stops bridging channels SIP/1111-00000007<ZOMBIE> and SIP/1111-00000006 chan_dahdi.c: Requested indication 22 on channel DAHDI/i1/87133306-3 sig_pri.c: Received AST_CONTROL_CONNECTED_LINE on DAHDI/i1/87133306-3 chan_dahdi.c: 1 Adding facility ie contents to send in FACILITY message: chan_dahdi.c: 1 ASN.1 dump chan_dahdi.c: 1 Context Specific/C [1 0x01] <A1> Len:24 <18> chan_dahdi.c: 1 Integer(2 0x02) <02> Len:1 <01> chan_dahdi.c: 1 <03> - "~" chan_dahdi.c: 1 OID(6 0x06) <06> Len:6 <06> chan_dahdi.c: 1 <04 00 82 71 01 05> - "~~~q~~" chan_dahdi.c: 1 Sequence/C(48 0x30) <30> Len:11 <0B> chan_dahdi.c: 1 Enumerated(10 0x0A) <0A> Len:1 <01> chan_dahdi.c: 1 <01> - "~" chan_dahdi.c: 1 Context Specific/C [0 0x00] <A0> Len:6 <06> chan_dahdi.c: 1 Context Specific [0 0x00] <80> Len:4 <04> chan_dahdi.c: 1 <30 31 30 32> - "0102" chan_dahdi.c: 1 ASN.1 end chan_dahdi.c: 1 INVOKE Component Context Specific/C [1 0x01] chan_dahdi.c: 1 invokeId Integer(2 0x02) = 3 0x0003 chan_dahdi.c: 1 operationValue OID(6 0x06) = 4.0.369.1.5 chan_dahdi.c: 1 operationValue = ROSE_ETSI_EctInform chan_dahdi.c: 1 EctInform Sequence/C(48 0x30) chan_dahdi.c: 1 callStatus Enumerated(10 0x0A) = 1 0x0001 chan_dahdi.c: 1 redirectionNumber PresentedNumberUnscreened chan_dahdi.c: 1 Explicit Context Specific/C [0 0x00] chan_dahdi.c: 1 presentationAllowedNumber PartyNumber chan_dahdi.c: 1 unknownPartyNumber Context Specific [0 0x00] = "0102" chan_dahdi.c: 1 chan_dahdi.c: 1 > DL-DATA request chan_dahdi.c: 1 > Protocol Discriminator: Q.931 (8) len=34 chan_dahdi.c: 1 > TEI=0 Call Ref: len= 2 (reference 43/0x2B) (Sent to originator) chan_dahdi.c: 1 > Message Type: FACILITY (98) chan_dahdi.c: 1 TEI=0 Transmitting N(S)=43, window is open V(A)=43 K=7 chan_dahdi.c: 1 chan_dahdi.c: 1 > Protocol Discriminator: Q.931 (8) len=34 chan_dahdi.c: 1 > TEI=0 Call Ref: len= 2 (reference 43/0x2B) (Sent to originator) chan_dahdi.c: 1 > Message Type: FACILITY (98) chan_dahdi.c: 1 > [1c 1b 91 a1 18 02 01 03 06 06 04 00 82 71 01 05 30 0b 0a 01 01 a0 06 80 04 30 31 30 32] chan_dahdi.c: 1 > Facility (len=29, codeset=0) [ 0x91, 0xA1, 0x18, 0x02, 0x01, 0x03, 0x06, 0x06, 0x04, 0x00, 0x82, 'q', 0x01, 0x05, '0', 0x0B, 0x0A, 0x01, 0x01, 0xA0, 0x06, 0x80, 0x04, '0102' ] channel.c: Hanging up channel 'SIP/1111-00000006' app_dial.c: Exiting with DIALSTATUS=ANSWER. pbx.c: Spawn extension (inbound_all,s,2) exited non-zero on 'SIP/1111-00000007<ZOMBIE>' pbx.c: == Spawn extension (inbound_all, s, 2) exited non-zero on 'SIP/1111-00000007<ZOMBIE>' channel.c: Soft-Hanging up channel 'SIP/1111-00000007<ZOMBIE>' channel.c: Hanging up zombie 'SIP/1111-00000007<ZOMBIE>' chan_sip.c: Stopping retransmission on '4e4d6d5a1152cff85ed7c18c6ed2b7a9@172.20.45.10' of Request 103: Match Found res_rtp_asterisk.c: No remote address on RTP instance '0x7f3a46298488' so dropping frame res_rtp_asterisk.c: No remote address on RTP instance '0x7f3a46298488' so dropping frame res_rtp_asterisk.c: No remote address on RTP instance '0x7f3a46298488' so dropping frame chan_sip.c: Stopping retransmission on '565a02b66888481b6862e89b53af39ee@172.20.45.10' of Request 103: Match Found res_rtp_asterisk.c: No remote address on RTP instance '0x7f3a46298488' so dropping frame res_rtp_asterisk.c: Setting RTCP address on RTP instance '0xa29ef8' res_rtp_asterisk.c: No remote address on RTP instance '0x7f3a46298488' so dropping frame chan_dahdi.c: 1 chan_dahdi.c: 1 < Protocol Discriminator: Q.931 (8) len=9 chan_dahdi.c: 1 < TEI=0 Call Ref: len= 2 (reference 43/0x2B) (Sent from originator) chan_dahdi.c: 1 < Message Type: DISCONNECT (69) chan_dahdi.c: 1 < [08 02 82 e5] chan_dahdi.c: 1 < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Public network serving the local user (2) chan_dahdi.c: 1 < Ext: 1 Cause: Message not compatible with call state (101), class = Protocol Error (e.g. unknown message) (6) ] chan_dahdi.c: 1 Received message for call 0xa285f0 on 0x7f3a46225b30 TEI/SAPI 0/0, call->pri is 0x7f3a46225b30 TEI/SAPI 0/0 chan_dahdi.c: 1 -- Processing IE 8 (cs0, Cause) chan_dahdi.c: 1 -- Found active call: 0xa285f0 cref:43 chan_dahdi.c: 1 q931.c:7201 post_handle_q931_message: Call 43 enters state 12 (Disconnect Indication). Hold state: Idle sig_pri.c: Span: 1 Processing event: PRI_EVENT_HANGUP_REQ sig_pri.c: -- Channel 0/7, span 1 got hangup request, cause 101 {noformat} My chan_dahdi.conf: {noformat} signalling = pri_cpe switchtype=euroisdn pridialplan=unknown prilocaldialplan=national resetinterval = 3600 usecallerid=yes threewaycalling=no facilityenable=no transfer=no context = from_e1_provider1 group=0 channel => 1-15,17-31 {noformat} | ||||
Comments: | By: Michael Smith (asbestoshead) 2010-11-25 11:07:08.000-0600 This feature was added in ASTERISK-8584 and ASTERISK-13210. By: Michael Smith (asbestoshead) 2010-11-25 12:53:25.000-0600 The attached patch does the trick for me. I just have to set this in chan_dahdi.conf: ; Prevent connected line updates from being sent to the PRI. setvar=__CONNECTED_LINE_CALLER_BLOCK=1 ;setvar=__REDIRECTING_CALLER_BLOCK=1 By: Paul Belanger (pabelanger) 2010-11-25 15:01:06.000-0600 Your code should be moved into a function, since the logic is the same. By: Michael Smith (asbestoshead) 2010-11-25 15:33:15.000-0600 Which code? By: Paul Belanger (pabelanger) 2010-11-25 16:53:18.000-0600 All of it, there is no point using the same code in both ast_channel_redirecting_macro() and ast_channel_connected_line_macro(). Create a function and call it. By: Michael Smith (asbestoshead) 2010-11-25 19:05:12.000-0600 Something like this? The problem is both ast_channel_connected_line_macro() and ast_channel_redirecting_macro() have identical structure. It's hard to refactor them because they use different names and data types on almost every line. Going up a level, most of the calls to *_macro() follow a pattern like: if (*_macro() doesn't return 0) { /* some update code that's also in *_macro() */ } It could all use a little rework but I don't have the resources to test all callers and I'm afraid I don't know enough about what's going on for many of them. By: Michael Smith (asbestoshead) 2010-12-01 07:56:11.000-0600 Ping By: Cristian Dimache (cristiandimache) 2011-08-20 08:10:46.186-0500 I've got into this issue also: [Aug 20 09:33:04] VERBOSE[6682] chan_dahdi.c: PRI Span: 2 > DL-DATA request [Aug 20 09:33:04] VERBOSE[6682] chan_dahdi.c: PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=33 [Aug 20 09:33:04] VERBOSE[6682] chan_dahdi.c: PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 610/0x262) (Sent from originator) [Aug 20 09:33:04] VERBOSE[6682] chan_dahdi.c: PRI Span: 2 > Message Type: FACILITY (98) ... and then the provider DISCONNECTs the call... [Aug 20 09:33:04] VERBOSE[2429] chan_dahdi.c: PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=13 [Aug 20 09:33:04] VERBOSE[2429] chan_dahdi.c: PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 627/0x273) (Sent to originator) [Aug 20 09:33:04] VERBOSE[2429] chan_dahdi.c: PRI Span: 2 < Message Type: DISCONNECT (69) [Aug 20 09:33:04] VERBOSE[2429] chan_dahdi.c: PRI Span: 2 < [08 02 84 81] I did not use the attached patch (simply returned in ast_channel_update_connected_line and ast_channel_queue_connected_line_update), but I think it should be a per-span configuration in chan_dahdi.conf to enable or disable this FACILITY messages. This config option should default to "off", because it has the potential to break ISDN on some configurations (and it's quite difficult to debug) By: Cristian Dimache (cristiandimache) 2011-10-03 04:41:02.603-0500 Any ideas about the problems that could appear if we ignore line updates in channel.c? By: Gary Herbstman (gherbstman) 2011-12-09 05:51:21.005-0600 This needs to be extended to SIP trunks as well. I have two SIP trunk providers; VoicePulse and CallCentric, who are not compatible with COLP and it is causing drops. The only apparent setting to control this is sendrpid on the trunk but it affects both initial callerID as well as COLP. By: Richard Mudgett (rmudgett) 2012-03-15 18:29:53.589-0500 The channel variable approach is not the best way to approach this problem. Each channel driver should be able to block the connected line updates. Chan_sip already has config options to do this. I have committed a patch on trunk to chan_dahdi to add an option to do this. |