[Home]

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-0600Date Closed:2012-03-15 18:29:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-18999 Connected Line updates need a disable option on a per SIP device / trunk basis.
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.