[asterisk-dev] [Code Review] Connected line update on sig_analog, sig_pri, and chan_misdn call transfers
rmudgett at digium.com
rmudgett at digium.com
Wed Nov 3 15:58:56 CDT 2010
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/996/
-----------------------------------------------------------
Review request for Asterisk Developers and Russell Bryant.
Summary
-------
This patch is a follow on to https://reviewboard.asterisk.org/r/958/ and is also against the 1.8 branch.
It adds connected line update for sig_analog transfers and simplifies the sig_pri and chan_misdn transfer code.
Diffs
-----
/branches/1.8/channels/chan_misdn.c 293883
/branches/1.8/channels/sig_analog.c 293883
/branches/1.8/channels/sig_pri.c 293883
/branches/1.8/include/asterisk/channel.h 293883
/branches/1.8/main/channel.c 293883
Diff: https://reviewboard.asterisk.org/r/996/diff
Testing
-------
Call transfers still work and the connected line information is updated. Also the expected caller/callee connected line interception macros are run on each channel.
Basic transfer actions:
A calls B
A places B on hold
A calls C
A can optionally swap between B and C by flash hook.
A transfers B to C
Test cases:
1) A transfers B to C using hangup.
2) A transfers B to C using hangup while C ringing.
3) A transfers C to B using hangup.
4) A transfers B to C using ECTExecute message.
5) A transfers B to C using ECTExecute message while C ringing.
6) A transfers C to B using ECTExecute message.
Note that chan_misdn supports test cases 1 - 3.
Note that sig_analog supports test cases 1 - 2.
Note that if you create a three-way call in sig_analog before transferring the call, the distinction of the caller/callee interception macros make little sense. The interception macro writer needs to be prepared for either caller/callee macro to be executed. The current implementation swaps which caller/callee interception macro is executed after a three-way call is created.
Thanks,
rmudgett
More information about the asterisk-dev
mailing list