[Home]

Summary:ASTERISK-08293: Inbound Caller Does Not Hear Ringing
Reporter:damin (damin)Labels:
Date Opened:2006-12-06 11:28:00.000-0600Date Closed:2011-06-07 14:03:08
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 48371-revert.diff
( 1) iax2-debug-rev48106.txt
( 2) iax2-trace-rev48106.cap
( 3) pri-debug-with-app_ringing.txt
( 4) pri-debug-wout-app_ringing.txt
( 5) show-channel-output.txt
( 6) sip-sip.cap
( 7) sip-sip-trace.txt
Description:For lcck of a better idea if where specifically this issue is originating, I'm putting it in as an IAX bug because in my setup, it's all IAX2 between servers.

Two people have reported the same problem w/ SVN-branch-1.2-r48192 on #asterisk-dev, and I have replicated this on two servers in my facility.

We used to use the following Dial Plan for receiving an inbound Zap call and sending it off to another box. The inbound context simply issues a "Dial()" command using IAX w/ no other parameters.

[from-xo]
exten => _NXXNXXXXXX,1,Wait(0.5)
exten => _NXXNXXXXXX,2,Goto(inbound,${EXTEN},1)

When we upgraded to r48192 this weekend, the ringing indication stopped and we were had to add the following to get it back:

[from-xo]
exten => _NXXNXXXXXX,1,Ringing()
exten => _NXXNXXXXXX,2,Wait(0.5)
exten => _NXXNXXXXXX,3,Goto(inbound,${EXTEN},1)

Since I'm running on production servers, I'll try to hone in on a specific patch that might have affected this
Comments:By: Joshua C. Colp (jcolp) 2006-12-06 11:53:23.000-0600

An iax2 debug and show channel on channels where this issue occurred would have been nice too.
By: damin (damin) 2006-12-06 12:42:38.000-0600

As I said on IRC and in the ticket, I'll have to get more information on this later, but I opened the ticket to be proactive so that others could post their experiences / configs.
By: damin (damin) 2006-12-06 18:43:27.000-0600

I reverted to version 48106, and did some IAX2 traces (both Debug and tcpdump captures) which have been uploaded. Even in this version, the problem exists. You can clearly see from both files that the remote side (69.4.32.150) is indicating ringing.

So I'm starting to suspect chan_zap. I'm going to try to get some "show channel" output while the call is ringing.
By: damin (damin) 2006-12-06 19:13:58.000-0600

I've uploaded a "show channel" on all channels. They were not on the same call (as I'm only one person), but it should suffice. I tried to compare the output as best I could, and it should be close enough for darts. Let me know if anything else is needed?
By: damin (damin) 2006-12-06 19:18:22.000-0600

The IAX2 stuff looks right.

State 4 = local ringing
State 5 = remote ringing

The Zap channel looks right too...

I wonder.. Let me test this using a different provider (Easton instead of X/O).
By: damin (damin) 2006-12-06 19:24:12.000-0600

No go on this either.. used a different carrier on a different Zap group, same behavior.

tdm-1*CLI> show channel Zap/84-1
-- General --
          Name: Zap/84-1
          Type: Zap
      UniqueID: 1165454214.59
     Caller ID: (N/A)
Caller ID Name: (N/A)
   DNID Digits: 8665799545
         State: Ring (4)
         Rings: 1
  NativeFormat: 68
   WriteFormat: 64
    ReadFormat: 64
1st File Descriptor: 71
     Frames in: 447
    Frames out: 0
Time to Hangup: 0
  Elapsed Time: 0h0m9s
 Direct Bridge: <none>
Indirect Bridge: <none>
--   PBX   --
       Context: inbound
     Extension: 8665799545
      Priority: 1
    Call Group: 0
  Pickup Group: 0
   Application: Dial
          Data: IAX2/tdm-1@pbx1/2169203030
   Blocking in: ast_waitfor_nandfds
     Variables:
CALLEDTON=1
ANI2=0
TRANSFERCAPABILITY=SPEECH

 CDR Variables:
level 1: dst=8665799545
level 1: dcontext=inbound
level 1: channel=Zap/84-1
level 1: dstchannel=IAX2/pbx1-36
level 1: lastapp=Dial
level 1: lastdata=IAX2/tdm-1@pbx1/2169203030
level 1: start=2006-12-06 20:16:54
level 1: answer=2006-12-06 20:16:54
level 1: end=2006-12-06 20:16:54
level 1: duration=0
level 1: billsec=0
level 1: disposition=NO ANSWER
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1165454214.59

   -- Channel 0/12, span 4 got hangup request
   -- Hungup 'IAX2/pbx1-36'
By: damin (damin) 2006-12-06 21:52:43.000-0600

For giggles, I blew away my entire tree and removed all the modules, then rebuilt everything from fresh SVN (libpri, zaptel, asterisk). The current 1.2 (rev48322) exhibits the same behavior.


By: Matt O'Gorman (mogorman) 2006-12-07 10:00:29.000-0600

i take it this does not happen if you use sip or zap to connect these two boxes together.
By: damin (damin) 2006-12-07 16:55:37.000-0600

I will try setting up a SIP connection between the boxes, and no, it's probably not a Zap -> Zap problem.

What HAS been a workaround for us is to use the "Ringing()" application. However, there are lots of boxes w/ lots of entry contexts, and I'm sure we haven't hit them all, so some customers are just going "WTF?".
By: damin (damin) 2006-12-07 17:19:46.000-0600

Alright.. I setup a SIP connection between the two boxes and I get the same behavior. Logic leads me to believe that it is not an IAX or SIP bug then. Possibly an app_dial issue? chan_zap maybe?
By: damin (damin) 2006-12-07 17:25:22.000-0600

Per Mogs suggestion I have attached an intense PRI debug to look at the q931 messages.
By: damin (damin) 2006-12-07 18:36:24.000-0600

Added some sip - sip - sip traces and debugs.. Mog thinks it might be in app_dial's relaying of ringing states..
By: Joshua C. Colp (jcolp) 2006-12-11 10:44:28.000-0600

Here's an analysis of the IAX2 & sip debug, since I'm no PRI guru I can't go for that one.

IAX2:

1. Call is answered before ringing actually occurs.
2. Ringing is indicated from remote side.
3. Ringing gets transported over IAX2 out of band, and sent to bridged call to generate.

SIP:

1. Call is answered before ringing actually occurs.
2. Ringing is never received out of band (SIP don't work like 'dat), so it should have been generated on the remote side.

That's just based on iax2-debug-rev48106.txt and sip-sip-trace.txt
By: damin (damin) 2006-12-14 07:47:49.000-0600

I'm not sure if this is helpful, but since Mog suggested that this might be an issue w/ app_dial, I'm looking at the changelog for the upcoming 1.2.14 release and have found the following revisions, dating back to 1.2.13 (late October) that make modifications to app_dial:

2006-12-01 23:30 +0000 [r48192]  Kevin P. Fleming <kpfleming@digium.com>
      * apps/app_dial.c: if Dial() is going to send music-on-hold to the
        calling party, it has to send PROGRESS first to ensure that the
        reverse audio path has been setup first (BE-106)

2006-11-16 23:16 +0000 [r47780]  Jason Parker <jparker@digium.com>
      * apps/app_dial.c, apps/app_cut.c, apps/app_directory.c,
        apps/app_db.c: Fix a couple of typos in applications.. Initially
        spotted by mrobinson.

2006-09-19 16:21 +0000 [r43269]  Matt O'Gorman <mogorman@digium.com>
      * pbx/pbx_gtkconsole.c, apps/app_dial.c, channels/chan_sip.c,
        apps/app_macro.c, asterisk.c, config.c, apps/app_queue.c, pbx.c:
        fixes some verbose vs debug issues. patch from bug 2617

There also seems to be some modifications to channel drivers, specifically dealing w/ ringing:

2006-12-10 02:14 +0000 [r48371]  Steve Murphy <murf@digium.com>
      * channels/chan_zap.c: This version applies the patch suggested by
        stevens in bug 7836 (make inbound channel RINGING state
        consistent with other channels).
By: Joshua C. Colp (jcolp) 2006-12-14 10:08:10.000-0600

Hey Damin - can you give the attached a try just for kicks? It reverts the ringing mods in zaptel... one of them was questionable from my perspective. Give it a go!
By: Serge Vecher (serge-v) 2006-12-14 12:41:30.000-0600

wasn't the problem reported for 48322, prior to 48371 commit?
By: damin (damin) 2007-01-12 10:40:16.000-0600

This is actually coming back up again. I am going to do a complete re-build of the source tree this weekend and see if the current SVN revs have any positive impact on this.
By: Jason Parker (jparker) 2007-01-16 15:38:42.000-0600

It's Tuesday now...  any luck with this?
By: Joshua C. Colp (jcolp) 2007-02-13 19:41:42.000-0600

it's also Tuesday now a month away - any news?
By: damin (damin) 2007-02-14 14:26:39.000-0600

<Damin> file: Regarding the IAX2 non ringing issue..
<Damin> file: It's still an issue for us..
<Damin> file: I haven't been able to track it down..
<Damin> file: The boxes in question are production boxes, and short of doing it at 3:00 AM there is not much that I can do
         at this point..
<Damin> file: Our workaround has been to use the "Ringing()" application, which is kind of a pain..
By: Serge Vecher (serge-v) 2007-03-14 08:39:36

another month ... what to do with this high priority bug ...
By: damin (damin) 2007-03-14 08:48:57

I devoted significant hours to this, and offered to provide access to the running systems for diagnostic purposes. No one took me up on the offer at the time the problem was easily reproducible. We have a workaround in place that is functioning for most puposes.

I simply cannot risk affecting customers on a production systems for further debugging on this, and it appears that Digium cannot replicate it in the lab.

I do not have the resources to further debug this.
By: Joshua C. Colp (jcolp) 2007-06-18 13:37:56

This bug is going nowhere quickly and nobody else has commented that they too are having the issue... so I'm suspending it for now.