Review Board 1.7.16

Fix up indications issues related to redirects

Review Request #90 - Created Dec. 12, 2008 and submitted

Russell Bryant
This patch was written to resolve issue #13747.

The issue that was reported was about a case where a RINGING channel got redirected to an extension to pick up a call from parking.  Once the parked call got taken out of parking, it heard silence until the other side answered.  Ideally, the caller that was parked would get a ringing indication.  This patch fixes this case so that the caller receives ringback once it comes out of parking until the other side answers.

The fixes are:

1) Make sure we remember that a channel was an outgoing channel when doing a masquerade.  This prevents an erroneous ast_answer() call on the channel, which causes a bogus 200 OK to be sent in the case of SIP.

2) Add some additional comments to explain related parts of code.

3) Update the handling of the ast_channel visible_indication field.  Storing values that are not stateful is pointless.  Control frames that are events or commands should be ignored.

4) When a bridge first starts, check to see if the peer channel needs to be given ringing indication because the calling side is still ringing.
1) SIP/5001 calls SIP/5004
2) SIP/5001 transfers SIP/5004 to parking

(5004 is now parked, 5001 idle)

3) Originate an outbount call to SIP/5001.
4) Redirect the ringing channel to the proper extension to pick up the parked call.

Verified that after #4, 5001 was still ringing, and that 5004 received ringback.

5) Answer SIP/5001

Verified that the callers could now talk as usual
Review request changed
Updated (Dec. 15, 2008, 2:12 a.m.)
Update diff to include a comment explaining the change in ast_bridge_call, as well as some re-work of ast_indicate_data() for the sake of readability
Ship it!
Posted (Dec. 15, 2008, 2:26 a.m.)
Looks good!
  1. Hmmm, once a shipit is attached, it's hard to add further comments...
    While it sounds like this is good, did you test it in the same fashion
    that the masq_park branch was tested? See my as-yet-not-submitted-
    reviewboard-issue; there are several paths into and out of parking.
    If it works in all cases, then I'd have to agree with jcolp.
    A calls B, B parks A
    A calls B, A parks B
    parking is done by 'feature', Park() app, etc.
    It may seem like useless repitition, but sometimees there's
    surprises best found early than late.
  2. I did not test multiple methods to get into parking since this issue only affects a specific method for taking a call back out of parking.  How it got there shouldn't matter, in theory.  :-)
  3. Parking itself is not really the issue here 'nor should it matter so I think testing all of those various scenarios would be a waste of time. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to