Hi Jousha,
No changes were made there the caller when clicks the transfer button send
INACTIVE then start the REFER process , the transfer completed fine but the
call in still in inactive state.
I can't change the caller behaviour so I had to change the Asterisk code a
few minutes ago :)
found my way through in bridge_channel.c
*ast_set2_flag(&bridge->feature_flags, dissolve,
AST_BRIDGE_FLAG_DISSOLVE_EMPTY);*
+ ch1 = AST_LIST_FIRST(&bridge->channels);
+ if (ast_channel_hold_state(ch1->chan) == AST_CONTROL_HOLD ) {
+ ast_indicate(ch1->chan, AST_CONTROL_UNHOLD);
+}
This will happen only when swapping channels so it won't affect the normal
bridge operations and of course I'd like to get your input if there a
better place to have this patch.
On Sun, Dec 13, 2020 at 12:22 PM Joshua C. Colp <jc...@sangoma.com> wrote:
> On Sun, Dec 13, 2020 at 1:57 AM Ahmed Fouad <afo...@gmail.com> wrote:
>
>> Hi,
>>
>> I've a situation with remote attended transfer and like to solve it by
>> putting the 2nd channel in the bridge in UNHOLD state when swapping is
>> completed.
>> I started debugging the code with res_pjsip_refer.c: INVITE with Replaces
>> being attempted.
>>
>> I'm running Asterisk certified/16.8-cert3
>>
>> [Dec 12 12:03:20] DEBUG[10736] res_pjsip_refer.c: INVITE with Replaces
>> being attempted. 'PJSIP/XXXX-00000011' --> 'PJSIP/XXXX-0000000e'
>> [Dec 12 12:03:20] DEBUG[14235] bridge_channel.c: Bridge
>> 883a1d4a-580d-470d-8448-90b2a03b637b: 0x7f305403c998(PJSIP/XXXX-00000011)
>> is joining
>> [Dec 12 12:03:20] DEBUG[14235] bridge_channel.c: Bridge
>> 883a1d4a-580d-470d-8448-90b2a03b637b: pushing
>> 0x7f305403c998(PJSIP/XXXX-00000011) by swapping with
>> 0x7f305408bea8(PJSIP/XXXX-0000000e)
>> [Dec 12 12:03:20] DEBUG[14235] bridge_channel.c: Setting
>> 0x7f305408bea8(PJSIP/XXXX-0000000e) state from:0 to:2
>> [Dec 12 12:03:20] DEBUG[14235] bridge_channel.c: Bridge
>> 883a1d4a-580d-470d-8448-90b2a03b637b: pulling
>> 0x7f305408bea8(PJSIP/XXXX-0000000e)
>> [Dec 12 12:03:20] VERBOSE[14235] bridge_channel.c: Channel
>> PJSIP/XXXX-0000000e left 'simple_bridge' basic-bridge
>> <883a1d4a-580d-470d-8448-90b2a03b637b>
>> [Dec 12 12:03:20] DEBUG[14235] bridge_channel.c: Bridge
>> 883a1d4a-580d-470d-8448-90b2a03b637b: 0x7f305408bea8(PJSIP/XXXX-0000000e)
>> is leaving simple_bridge technology
>> [Dec 12 12:03:20] VERBOSE[14235] bridge_channel.c: Channel
>> PJSIP/XXXX-00000011 swapped with PJSIP/XXXX-0000000e into 'simple_bridge'
>> basic-bridge <883a1d4a-580d-470d-8448-90b2a03b637b>
>> [Dec 12 12:03:20] DEBUG[14235] bridge_native_rtp.c: Bridge
>> '883a1d4a-580d-470d-8448-90b2a03b637b'. Checking compatability for
>> channels '*PJSIP/pstn-0000000f*' and 'PJSIP/XXXX-00000011'
>>
>> In this step I'd like to make sure that the other channel
>> *PJSIP/pstn-0000000f* in the bridge is off hold or put it off-hold.
>>
>> How can I accomplish it
>> ?
>>
>
> I believe such things should already happen[1], but if I recall you posted
> on the community forum about other code modifications[2]. Have you done
> changes in the SDP side? Otherwise you'd need to show exactly what is
> happening.
>
> [1]
> https://github.com/asterisk/asterisk/blob/certified/16.8/main/bridge.c#L4779
> [2]
> https://community.asterisk.org/t/chan-pjsip-add-support-for-passing-hold-and-unhold-requests-through/86738
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Best Regards,
Ahmed Fouad
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
