[Home]

Summary:ASTERISK-17328: When using ugc in dial - If first leg hangs up call is in limbo
Reporter:dovid (dovid)Labels:
Date Opened:2011-02-01 05:40:04.000-0600Date Closed:2011-06-07 14:04:54
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full.5
( 1) not_working.cap
Description:Hi,

If phone1 calls phone2 with a gosub (sent because of u in dial string) that sends that sends the called party to a macro where they have to enter DTMF to have the call bridged, if the caller hangs up after the called person picks up the first leg is in limbo.

1) phone1 calls phone2
2) phone2 picks up and is sent to a GoSub where a message is played for phone2 to enter dtmf to bridge the calls.
3) phone2 does not enter anything and hears the message over and over.
4) phone1 hangs up the phone. Asterisk gets the BYE and sends a 200 in response, however the call is not hung up and the call is in limbo till phone2 enters DTMF or hangs up.

I will upload the full log as well as a tshark trace.

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

Dial Plan:
[bug-test]

Exten => _X,1,NoOp()
Exten => _X,2,Dial(SIP/phone${EXTEN},60,gcU(do_dtmf_cc-take-call,s,1))
Exten => _X,3,Playback(tt-monkeys)
Exten => _X,4,Playback(tt-monkeys)
Exten => _X,5,Playback(tt-monkeys)

Exten => h,1,Noop(ABCDEFGHIJKLMNOPQRSTUVWXYZ)

[do_dtmf_cc-take-call]
Exten => s,1,Background(vm-press)
Exten => s,2,WaitExten(2)
Exten => s,3,Goto(s,1)

Exten => _X,1,Noop(LOOKS LIKE THEY PRESSED ${EXTEN}

Exten => h,1,Noop(------------------------------------------)

Comments:By: dovid (dovid) 2011-02-01 05:45:15.000-0600

Server: 192.168.1.240
phone1: 192.168.1.211
phone2: 192.168.1.203
By: John Covert (jcovert) 2011-02-06 22:48:08.000-0600

I don't see why this is a bug.

I used precisely this concept (except with a Macro rather than a gosub) to deliver calls to all of my phones when one of them included a desk phone at a client's office --- desk phone had voicemail and I didn't want my calls from other clients answered by Acme Sprocket's voicemail.

I would expect to actually get the message from the incoming caller even if the incoming call had hung up so I wouldn't wonder what the dropped call is about.

The gosub (or macro) should set an absolute timeout when it starts which is shorter than the length of the OGM on the voicemail (if there is VM) so that phantom VM isn't left.  It should clear it when the TT is entered before exiting the GoSub to allow the incoming and outgoing channels to bridge.

Do I get your bounty?


By: John Covert (jcovert) 2011-02-06 23:01:25.000-0600

Another way to do something in the Gosub would be to pass a variable through (be sure to prefix it with at least one, probably two underscores) that you set through the dialplan with the name of the originating channel; the gosub could then check for the originating channel's continued existence.

Bottom line: I don't think there's a bug here.

The reason the terminating channel doesn't go away is that these are really two independent channels until they bridge, which isn't going to happen until the Gosub exits.

In any case, with the info I've provided, you can make your application work and be aware in the terminating channel that the caller hung up.

/john
By: dovid (dovid) 2011-02-07 05:27:04.000-0600

John,

I understand what you are saying that there are two calls that are bridged once the GoSub exits. However this is the same for all calls. Any time a call is made there are two calls that are bridged together. If one leg hangs up then Asterisk hangs up the second leg.

What you suggested to see if the original channel is up is work around (I did not know that there is a way of checking if a channel is up thinking about it now I can use the AMI) is a "hack fix" but solving the issue that the call should hang up.

Whats interesting is that Asterisk gets the BYE sends the 200 OK but does not even hang up the first call.
By: John Covert (jcovert) 2011-02-07 08:16:28.000-0600

In your example, if the called party doesn't press within 10 seconds, whack it:

Exten => s,1,Background(vm-press)
Exten => s,n,WaitExten(2)
Exten => s,n,GotoIf($[${SET(c=$[0${c} + 1])} < 5]?s,1)
Exten => s,n,Set(GOSUB_RESULT=CONTINUE) ; or BUSY - whatever is appropriate for overall application
Exten => s,n,Return

I'm not sure that the current behaviour is a bug or should be changed.


By: dovid (dovid) 2011-02-07 09:06:38.000-0600

jcovert:

What you suggested has nothing to do with the other channel. I have some one working on a patch.
By: John Covert (jcovert) 2011-02-07 09:36:59.000-0600

But it does hang up the other channel.

Maybe if I saw your entire application, I'd understand why you need a patch to accomplish anything here.
By: Robert Huddleston (redhatnc) 2011-02-07 10:00:52.000-0600

Even with the addition of the "H" argument (and pressing *) - it would appear that the caller is unable to hang up / terminate the call.
By: Leif Madsen (lmadsen) 2011-02-07 10:56:01.000-0600

I'm kind of in agreement with John here. The calls aren't bridged yet, which means they are independent channels from each other, and thus hanging up one channel shouldn't necessarily drop the other leg (since all of the GoSub() stuff is going to happen BEFORE the channels are bridged).

I personally don't consider this a bug here.
By: dovid (dovid) 2011-02-07 16:08:25.000-0600

jcovert:

It does not hang up the other channel. It hangs in limbo.

lmadsen:

From a coding perspective I could agree with you since it is doing what the code says to do. Aren't all bugs just doing what they are told ;) ?

The reason why I see it as a bug is when you make a call when the caller hangs up you would not want to keep going with the called party. If you call some one with call screening and the caller hangs up does it make sense to keep screening the call to the person being called ? I don't see this as any different then when you are placing a call to some one and then you decide to hang up because they are not answering.
By: John Covert (jcovert) 2011-02-07 17:11:42.000-0600

You're right.  Sorry.

At first glance, when the gosub exits, the originating channel is no longer in limbo, and hangs up.


I was going to continue to insist that there was no problem, because of this:

... the Gosub sets a status (any status, really) and returns.

   -- Executing [s@do_dtmf_cc-take-call:3] GotoIf("SIP/x28-00000097", "0?s,1") in new stack
   -- Executing [s@do_dtmf_cc-take-call:4] Set("SIP/x28-00000097", "GOSUB_RESULT=CONTINUE") in new stack
   -- Executing [s@do_dtmf_cc-take-call:5] Return("SIP/x28-00000097", "") in new stack
   -- Executing [s@app_dial_gosub_virtual_context:1] NoOp("SIP/x28-00000097", "") in new stack
   -- Auto fallthrough, channel 'SIP/x28-00000097' status is 'UNKNOWN'

I thought maybe this was a potential but unimportant cleanup need:
[Feb  7 18:01:21] ERROR[5690]: app_dial.c:2523 dial_exec_full: Could not stop autoservice on calling channel

And I thought this was a complete exit for the calling channel:
 == Spawn extension (bug-test, s, 2) exited non-zero on 'SIP/x37-00000096'
   -- Executing [h@bug-test:1] NoOp("SIP/x37-00000096", "ABCDEFGHIJKLMNOPQRSTUVWXYZ") in new stack

After all:

asterisk*CLI> core show channels
Channel              Location             State   Application(Data)            
0 active channels
0 active calls
114 calls processed


However...

asterisk*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer      
192.168.0.41     x37              3c64135d106d-aw  0x0 (nothing)    No       Rx: BYE                    x37      
192.168.0.41     x37              3c6412ca2d61-bk  0x0 (nothing)    No       Rx: BYE                    x37      
192.168.0.41     x37              3c64919923fe-jt  0x0 (nothing)    No       Rx: BYE                    x37      
192.168.0.41     x37              3c6417a5ed3f-i8  0x0 (nothing)    No       Rx: BYE                    x37      
192.168.0.41     x37              3c6415c7efe6-hp  0x0 (nothing)    No       Rx: BYE                    x37      
192.168.0.41     x37              3c6406d7aa5c-6m  0x0 (nothing)    No       Rx: BYE                    x37      
192.168.0.41     x37              3c649171941e-fh  0x0 (nothing)    No       Rx: BYE                    x37  

I admit to being wrong.
By: Leif Madsen (lmadsen) 2011-02-07 22:34:41.000-0600

And what version are you using? I know Terry was working on some patch that went in (I think) to make sure BYEs were not hanging around, but I can't remember the exact situation.

Make sure you're testing against the latest branch.
By: dovid (dovid) 2011-02-07 23:42:30.000-0600

jcovert:

It is more than that. The caller will only go to the h extension if the caller party enters DTMF or hangs up.
By: John Covert (jcovert) 2011-02-08 07:03:04.000-0600

I'm using chan_sip.c 302414, and I don't see anything through 306619 which would clean up the dangling channels.  There's something for continuously sending "BYE", but that's not the case here.

Dovid: not true if you exit from the gosub, as I displayed above:

 == Spawn extension (bug-test, s, 2) exited non-zero on 'SIP/x37-000000b2'
   -- Executing [h@bug-test:1] NoOp("SIP/x37-000000b2", "ABCDEFGHIJKLMNOPQRSTUVWXYZ") in new stack

Please make the change I suggested to your gosub.
By: Robert Huddleston (redhatnc) 2011-02-08 07:26:48.000-0600

I agree with lmadsen - there appears to be something going on with chan_sip - I never saw a hangup actually occur. And I never was able to get the * (asterisk DTMF) to recognize on the caller side to disconnect the call. Called party * worked but not caller - this was with Hh applied
By: dovid (dovid) 2011-02-08 10:43:12.000-0600

jocvert:

Thats exactly my point. It should hang up (or at least in my opinion) before the go sub ends. I do not want to exit as in my scenario I am doing call screening. I am not going to jump out because they didn't do something the first time. If I repeat the message to them say three times and the caller already hung up I have no way of knowing that

I am thinking now that what I can do is maybe jump in and out of the GoSub depending if the user entered DTMF.

Also even if you want to say that it should not hang up the second leg why does the first leg not hang up. The caller will get a 200 to their BYE right away but  the h extension will not be called for the caller till something happens on the called party's side
By: dovid (dovid) 2011-02-16 06:42:01.000-0600

Update:

I just tested now. If you note the channel for legA, legB picks up while hearing the message, if legA hangs up and then you do a show channels verbose it is still there.

Dovid
By: Leif Madsen (lmadsen) 2011-03-09 14:07:32.000-0600

Dovid: no part of dialplan execution continues after a hangup, and GoSub() is no exception. This is not looking like a bug to me.
By: dovid (dovid) 2011-03-10 02:50:09.000-0600

I give up.