Review Board 1.7.16


Fix up indications issues related to redirects

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

Russell Bryant
/branches/1.4
13747
Reviewers
asterisk-dev
Asterisk
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.

https://reviewboard.asterisk.org/ 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 asteriskteam@digium.com.