[asterisk-dev] Controlling the flow of connected line info after attended transfer of stasis-controlled channels

Stephen Davies stephen.l.davies at gmail.com
Tue Oct 30 15:20:59 CDT 2018


Hi Richard,

Thanks for coming back to me.  I'll pull my source tree up to date and do
some more testing tomorrow.

Could you comment on why the Dial with ,,I doesn't block the connected line
update propagating from the called side of the dial back to the calling
side.  That is what it should do and that's how the code seems to work.  My
impression is that the processing of the REFER seems to propagated the
connected line update all the way back through to the original channel
despite this flag.

Lastly - can I use the interception macros since my channels are under ARI
control via Stasis so I don't have a pbx and the calls are setup from ARI
using the bridge and channel API and not by calling app_dial from anywhere.

Thanks

On Tue, 30 Oct 2018 at 21:29, Richard Mudgett <rmudgett at digium.com> wrote:

>
>
> On Tue, Oct 30, 2018 at 2:02 PM Stephen Davies <stephen.l.davies at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm looking to see if I've missed something - if not I think there is an
>> ARI limitation worth thinking about.
>>
>> app_dial offers a flag "I" which is supposed to block propagation of
>> connected line updates through the dial bridge.  Is there anything like
>> this that I can do when setting up and managing a bridge with ARI?
>>
>> My problem is like so:  I have an incoming call from an "external" source
>> to a DDI.  I want to send that source a Remote-Party-Id containing the DDI
>> dialled an a name like "ABC Corp".  And I don't want that to change even
>> with subsequent transfers etc.
>>
>> I've got this working for the initial incoming call.  My problem comes
>> when the dialled phone does a transfer - specifically I've need testing
>> with attended transfer.
>>
>> (An attended transfer starts with the transferer initiating an "enquiry
>> call".  So two bridges.  On the REFER Asterisk does an attended transfer
>> with type "link" and inserts a Local channel pair between the two bridges,
>> replacing the two channels to the transferring phone.
>>
>> At this point Asterisk sends the original caller a connected line update
>> saying that "you are now talking to 201 Abu".  And tells the target phone
>> "you are now talking to the external caller".
>>
>> Which is true, no doubt, but in this case I want to block the connected
>> line update being sent to the original caller.
>>
>> Is there any way in the ARI API?  I can't find it.
>>
>> In related news, I tried to "isolate" my external caller by passing the
>> incoming call through a Local channel with the I option on the dial.  To
>> create a point where the connected line update with be blocked.  My
>> reasoning is then that the Attended transfer can do what it wants to the
>> channels in the bridge, but the flag in the dial will isolate the original
>> calling channel  My ARI app can directly tinker with the channel if I do
>> want to adjust the connected line info - but its 100% under my control.
>>
>> So I made my dialplan do this:
>>
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at from-drachtio:1] Goto("PJSIP/drachtio-sip1-00000045",
>> "to-stasis-ariapp,2710900XXXX,1") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx_builtins.c: Goto
>> (to-stasis-ariapp,2710900XXXX,1)
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp:1] Set("PJSIP/drachtio-sip1-00000045",
>> "app=ariapp") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp:2] ExecIf("PJSIP/drachtio-sip1-00000045",
>> "0?Set(app=ariapp)") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp:3] Set("PJSIP/drachtio-sip1-00000045",
>> "direction=inbound") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp:4] GotoIf("PJSIP/drachtio-sip1-00000045",
>> "1?to-stasis-ariapp-via-local,2710900XXXX,1") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx_builtins.c: Goto
>> (to-stasis-ariapp-via-local,2710900XXXX,1)
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp-via-local:1]
>> NoOp("PJSIP/drachtio-sip1-00000045", "Routing inbound call "0878XXXXXX"
>> <0878XXXXXX> -> 2710900XXXX via Local channel to block connected line
>> updates") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp-via-local:2]
>> Dial("PJSIP/drachtio-sip1-00000045",
>> "Local/2710900XXXX at to-stasis-ariapp-inbound/n,,I") in new stack
>> [Oct 30 17:51:21] VERBOSE[20289][C-00000015] app_dial.c: Called
>> Local/2710900XXXX at to-stasis-ariapp-inbound/n
>> [Oct 30 17:51:21] VERBOSE[20291][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp-inbound:1]
>> NoOp("Local/2710900XXXX at to-stasis-ariapp-inbound-00000006;2", "Routing
>> inbound call "0878XXXXXX" <0878XXXXXX> -> 2710900XXXX other side of local
>> channel") in new stack
>> [Oct 30 17:51:21] VERBOSE[20291][C-00000015] pbx.c: Executing
>> [2710900XXXX at to-stasis-ariapp-inbound:2]
>> Stasis("Local/2710900XXXX at to-stasis-ariapp-inbound-00000006;2",
>> "ariapp,"0878XXXXXX <0878XXXXXX>,2710900XXXX,inbound") in new stack
>>
>> So what's interesting about this is that is does prevent connected line
>> updates during the initial setup of the call:
>>
>> [Oct 30 17:51:24] VERBOSE[20289][C-00000015] app_dial.c: Connected line
>> update to PJSIP/drachtio-sip1-00000045 prevented.
>>
>> However the attended transfer still results in a connected-line update
>> being sent put to the calling channel through the dial into the Local
>> channel despite the I flag.
>>
>> My Asterisk is "Asterisk GIT-master-9189c26M" - which is a master branch
>> from shortly before 16 was released.
>>
>> Thanks for any pointers.
>>
>
> Look at
> https://gerrit.asterisk.org/#/c/asterisk/+/10286/
> which has been recently committed to the current branches and
> https://gerrit.asterisk.org/#/c/asterisk/+/10480/
> which is nearly ready to get merged.
>
> The other thing is to always use the connected line interception routine
> to manipulate the connected line information from what you are currently
> connected with to how you need it.
>
> https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
>
> https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines
>
> For the interception routine you can use the CONNECTEDLINE(tag) value to
> identify endpoint membership such as tenants.
> Note that there was a recent fix to the tag value in chan_pjsip:
> https://gerrit.asterisk.org/#/c/asterisk/+/10476/
>
> Richard
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Astricon is coming up October 9-11!  Signup is available at:
> https://www.asterisk.org/community/astricon-user-conference
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181030/ddd9a6e5/attachment-0001.html>


More information about the asterisk-dev mailing list