[Home]

Summary:ASTERISK-04353: NI-2 PROGRESS 'Call is not end-to-end ISDN; further call progress information may be available inband' not passed across IAX?
Reporter:kb1_kanobe2 (kb1_kanobe2)Labels:
Date Opened:2005-06-05 16:15:31Date Closed:2011-06-07 14:10:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cpe-PROGRESS-error.txt
( 1) progressdiff2.diff
( 2) progressfix.diff
( 3) pstn-PROGRESS-error.txt
( 4) rejected_call_setup.txt
( 5) successful_call_setup.txt
Description:When a call originating from DMS-100 PRI cpe attached to Asterisk is placed across an IAX channel to a remote NI-2 PRI net connection and the NI-2 switch returns:

[Span 0 D-Channel 0]< Call Ref: len= 2 (reference 2810/0xAFA) (Terminator)
[Span 0 D-Channel 0]< Message type: PROGRESS (3)
< [1e 02 8a 81]>
[Span 0 D-Channel 0]< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Network beyond the interworking point (10)
[Span 0 D-Channel 0]<                               Ext: 1  Progress Description: Call is not end-to-end ISDN; further call progress information may be available inband. (1) ]

then this indication is not communicated across the IAX leg and back to the DMS-100 PRI, resulting in a timer expiry on the cpe thus:

[Span 0 D-Channel 0]< Call Ref: len= 2 (reference 1/0x1) (Originator)
[Span 0 D-Channel 0]< Message type: DISCONNECT (69)
< [08 02 82 e6]CLI>
[Span 0 D-Channel 0]< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
[Span 0 D-Channel 0]<                  Ext: 1  Cause: Recover on timer expiry (102), class = Protocol Error (6) ]

Now, obviously there is a degree of protocol translation going on here but it seems there should still be an easy fix for this condition, either by passing the PROGRESS across the IAX network, or perhaps transitioning the cpe leg to a CONNECTED state (implied by 'inband progress information') if IAX doesn't provide a mechanism for conveying this state?

As a workaround for this situation it's possible to hard-code an Answer() into the dialplan on the originating Asterisk server prior to Dial()ing out across the IAX network. In that way the cpe falls directly into CONNECTED and the timers are satisfied. Ugly but effective...

****** ADDITIONAL INFORMATION ******

Not certain if this is better classified as a libpri issue, or an IAX issue so I thought I'd start here. As there is a workaround available I have marked this minor.

The equipment arrangement is: [Nortel MICS PBX cpe]<-(DMS-100)->[Asterisk PRI net]<-(IAX2)->[Asterisk PRI cpe]<-(NI-2)->[GDT-5 Switch net]...

The two attached pri debug traces contain a successful call (no PROGRESS message) and a failed call (PROGRESS received) placed with the same equipment but to different numbers. I have not attached a trace of the Answer() workaround as that should be self explanitory.
Comments:By: Kevin P. Fleming (kpfleming) 2005-06-21 20:06:55

Can you take a look at this and give us some idea whether there is a problem here that needs to be addressed? Thanks.
By: Matthew Fredrickson (mattf) 2005-07-13 14:38:23

Can you confirm whether or not there is actually an AST_CONTROL_PROGRESS frame actually passed over the IAX connection?
By: Matthew Fredrickson (mattf) 2005-07-14 06:18:04

I think I MAY have found out the reason why this isn't working.  If you are actually getting a PROGRESS frame over the IAX trunk, I think that it's not being interpreted into a PROGRESS frame on the PRI because of some recent changes regarding this in chan_zap.c.
By: Matthew Fredrickson (mattf) 2005-07-18 15:29:50

No feedback.
By: kb1_kanobe2 (kb1_kanobe2) 2005-08-05 03:42:37

Sorry for the delay responding to this. I've just updated to this evenings CVS-HEAD and the issue is still occuring as originally described. I've attached logs from both the originating cpe-attached server and the bridging telco-attached server with 'iax debug' and 'pri debug span 1' enabled. The Answer() workaround was disabled during the tests - hope this helps provide some insight.
By: Matthew Fredrickson (mattf) 2005-08-05 09:28:30

Check to see if the attached patch resolves this issue for you.
By: kb1_kanobe2 (kb1_kanobe2) 2005-08-05 10:50:57

I will patch it and test over the weekend, thanks!
By: kb1_kanobe2 (kb1_kanobe2) 2005-08-10 00:55:24

Sorry, that didn't quite do it. I've patched and restarted all the servers involved but I'm still not seeing the ISDN PROGRESS "Call is not end-to-end ISDN; further call progress information may be available inband."  message going out towards the PBX on the CPE side:

   -- Executing Dial("Zap/23-1", "IAX2/astpbx-pstn/916045825332@out-pstn") in new stack
   -- Called astpbx-pstn/916045825332@out-pstn
   -- Call accepted by 10.255.40.1 (format ulaw)
   -- Format for call is ulaw
Aug  9 22:53:32 DEBUG[9393]: chan_iax2.c:6521 socket_read: Ooh, voice format changed to 4
   -- IAX2/astpbx-pstn-1 is proceeding passing it to Zap/23-1
Aug  9 22:53:32 DEBUG[9421]: chan_zap.c:4565 zt_indicate: Requested indication 15 on channel Zap/23-1
Aug  9 22:53:32 DEBUG[9421]: chan_zap.c:4613 zt_indicate: Received AST_CONTROL_PROCEEDING on Zap/23-1
> Protocol Discriminator: Q.931 (8)  len=14
> Call Ref: len= 2 (reference 2/0x2) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 97]>
> 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: 23 ]
> [1e 02 81 88]CLI>
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8)  len=12
< Call Ref: len= 2 (reference 2/0x2) (Originator)
< Message type: STATUS (125)
< [08 02 82 e5]CLI>
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Unknown (101), class = Protocol Error (6) ]
< [14 01 03]rd*CLI>
< Call State (len= 3) [ Ext: 0  Coding: CCITT (ITU) standard (0) Call state: Outgoing call  Proceeding (3)
-- Processing IE 8 (cs0, Cause)
-- Processing IE 20 (cs0, Call State)
   -- IAX2/astpbx-pstn-1 is making progress passing it to Zap/23-1
Aug  9 22:53:33 DEBUG[9421]: chan_zap.c:4565 zt_indicate: Requested indication 14 on channel Zap/23-1
Aug  9 22:53:33 DEBUG[9421]: chan_zap.c:4631 zt_indicate: Received AST_CONTROL_PROGRESS on Zap/23-1
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 2/0x2) (Originator)
< Message type: DISCONNECT (69)
< [08 02 82 e6]CLI>
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Unknown (102), class = Protocol Error (6) ]
-- Processing IE 8 (cs0, Cause)
   -- Channel 0/23, span 1 got hangup request
Aug  9 22:53:41 DEBUG[9421]: chan_iax2.c:2965 iax2_hangup: We're hanging up IAX2/astpbx-pstn-1 now...
   -- Hungup 'IAX2/astpbx-pstn-1'
Aug  9 22:53:41 DEBUG[9421]: app_dial.c:1656 dial_exec_full: Exiting with DIALSTATUS=CANCEL.
 == Spawn extension (dialplan-routing, 916045825332, 2) exited non-zero on 'Zap/23-1'
Aug  9 22:53:41 DEBUG[9421]: chan_zap.c:2682 zt_setoption: Set option AUDIO MODE, value: ON(1) on Zap/23-1
Aug  9 22:53:41 DEBUG[9421]: chan_zap.c:2183 zt_hangup: Hangup: channel: 23 index = 0, normal = 43, callwait = -1, thirdcall = -1
Aug  9 22:53:41 DEBUG[9421]: chan_zap.c:2322 zt_hangup: Not yet hungup...  Calling hangup once with icause, and clearing call
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 2/0x2) (Terminator)
> Message type: RELEASE (77)
> [08 02 81 e6]CLI>
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Unknown (102), class = Protocol Error (6) ]
Aug  9 22:53:41 DEBUG[9421]: chan_zap.c:2592 zt_setoption: Set option TDD MODE, value: OFF(0) on Zap/23-1
Aug  9 22:53:41 DEBUG[9421]: chan_zap.c:1337 update_conf: Updated conferencing on 23, with 0 conference users
Aug  9 22:53:41 DEBUG[9421]: chan_zap.c:2676 zt_setoption: Set option AUDIO MODE, value: OFF(0) on Zap/23-1
   -- Hungup 'Zap/23-1'
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 2/0x2) (Originator)
< Message type: RELEASE COMPLETE (90)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
By: Matthew Simpson (matthewsimpson) 2005-08-12 00:31:57

my bug 4944 may be related
By: Matthew Fredrickson (mattf) 2005-08-16 16:24:19

I haven't had time to go back and look at this to make sure I did this right.  When I get a few more minutes I'll go back through this and see what else could be causing this to occur.
By: Matthew Fredrickson (mattf) 2005-08-19 12:51:18

It looks like it's getting a protocol error.  Did it still do that before you applied my patch?
By: dbruce (dbruce) 2005-08-19 17:22:45

The protocol error is probably being caused by the "display" IE... It is the only IE that is being sent that is not a mandatory IE for NI2. Not all systems support it, but most should just ignore it. However, if the switch is overly strict it may throw the protocol error and cause problems...

Looking at the original trace, this protocol error existed before the progressfix patch.

kb1_kenobe2: ask your provider if they support the display IE... and if they don't, what is their switch configured to do if it receives an IE that it considers invalid...

This protocol error is probably not related to the progress problem though...
By: Matthew Fredrickson (mattf) 2005-09-01 15:06:29

Can you get me access to the setup in question so that I can take a look at this problem as it occurs?
By: Matthew Fredrickson (mattf) 2005-09-06 19:54:08

No feedback
By: kb1_kanobe2 (kb1_kanobe2) 2005-09-13 14:22:02

Sorry for the delay responding to this issue - I have been away for the last month...

Mattf, I can set you up with shell access to my end for diagnostics as long as it's after about 7pm PST or on a weekend. I can also provide you with a PSTN number that can be dialed from your location (again late evening PST) that should generate the offending ISDN message sequence.

The protocol error is related to my telco (Telus), who accept the CallerID number but not the CallerID name and, yes, it's only a informational error. It occurs for every outbound call. :-)
By: kyreeth (kyreeth) 2005-09-20 23:47:25

This isn't limited to IAX-to-PRI, it also occurs when calling PRI-to-PRI. See http://host.feathers.net/~ashley/nonworkingcall for an example; for comparison, a working call is at http://host.feathers.net/~ashley/workingcall.
By: Matthew Fredrickson (mattf) 2005-09-29 17:19:56

I just rewrote part of how PRIs forward signalling data in chan_zap. Check to see if the attached patch fixes this.
By: Matthew Fredrickson (mattf) 2005-10-04 13:04:56

Fixed in head!
By: Digium Subversion (svnbot) 2008-01-15 15:50:00.000-0600

Repository: asterisk
Revision: 6711

U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r6711 | mattf | 2008-01-15 15:49:59 -0600 (Tue, 15 Jan 2008) | 4 lines

Rewrite of PRI progress and message handling.  Fixes bugs ASTERISK-5123 and ASTERISK-4353
(Early media related digit passing and passing early media progress between
channels)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6711