[asterisk-dev] [Code Review] Fix up indications issues related to redirects

[Russell Bryant]

> On 2008-12-15 08:26:25, Joshua Colp wrote:
> > Looks good!
> 
> Steve Murphy wrote:
>     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.
>     
>

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.  :-)


- Russell


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/90/#review224
-----------------------------------------------------------


On 2008-12-15 08:12:37, Russell Bryant wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/90/
> -----------------------------------------------------------
> 
> (Updated 2008-12-15 08:12:37)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> 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.
> 
> 
> This addresses bug 13747.
>     http://bugs.digium.com/view.php?id=13747
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/main/channel.c 164200 
>   /branches/1.4/res/res_features.c 164200 
> 
> Diff: http://reviewboard.digium.com/r/90/diff
> 
> 
> Testing
> -------
> 
> 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
> 
> 
> Thanks,
> 
> Russell
> 
>