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

[Stephen Davies]

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
[***@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
[***@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
[***@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
[***@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
[***@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
[***@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
[***@to-stasis-ariapp-via-local:2]
Dial("PJSIP/drachtio-sip1-00000045",
"Local/***@to-stasis-ariapp-inbound/n,,I") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] app_dial.c: Called
Local/***@to-stasis-ariapp-inbound/n
[Oct 30 17:51:21] VERBOSE[20291][C-00000015] pbx.c: Executing
[***@to-stasis-ariapp-inbound:1]
NoOp("Local/***@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
[***@to-stasis-ariapp-inbound:2]
Stasis("Local/***@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.

Steve Davies

[Richard Mudgett]

Post by Stephen Davies
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.
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"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
"app=ariapp") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"0?Set(app=ariapp)") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"direction=inbound") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"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
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
Dial("PJSIP/drachtio-sip1-00000045",
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] app_dial.c: Called
[Oct 30 17:51:21] VERBOSE[20291][C-00000015] pbx.c: Executing
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
"ariapp,"0878XXXXXX <0878XXXXXX>,2710900XXXX,inbound") in new stack
So what's interesting about this is that is does prevent connected line
[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

[Stephen Davies]

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

Post by Richard Mudgett

Post by Stephen Davies
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.
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"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
"app=ariapp") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"0?Set(app=ariapp)") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"direction=inbound") in new stack
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] pbx.c: Executing
"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
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
Dial("PJSIP/drachtio-sip1-00000045",
[Oct 30 17:51:21] VERBOSE[20289][C-00000015] app_dial.c: Called
[Oct 30 17:51:21] VERBOSE[20291][C-00000015] pbx.c: Executing
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
"ariapp,"0878XXXXXX <0878XXXXXX>,2710900XXXX,inbound") in new stack
So what's interesting about this is that is does prevent connected line
[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.
https://gerrit.asterisk.org/#/c/asterisk/+/10476/
Richard
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
https://www.asterisk.org/community/astricon-user-conference
asterisk-dev mailing list
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Stephen Davies]

Post by Stephen Davies
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.

Ah - my apologies, I see its actually documented:

The option blocks all redirecting updates since they should only happen

Post by Stephen Davies

before a call is answered. The option only blocks the connected line update
from the initial answer. Connected line updates resulting from call
transfers happen after the application has completed. Better control of
connected line and redirecting information is obtained using the
interception macros.

So its intended to work the way it works.

So its then important to understand how to use the interception macros or
some equivalent in the context of ARI.

Thanks,
Steve

[Richard Mudgett]

Post by Stephen Davies

Post by Stephen Davies
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.

The option blocks all redirecting updates since they should only happen

Post by Stephen Davies

before a call is answered. The option only blocks the connected line update
from the initial answer. Connected line updates resulting from call
transfers happen after the application has completed. Better control of
connected line and redirecting information is obtained using the
interception macros.

So its intended to work the way it works.
So its then important to understand how to use the interception macros or
some equivalent in the context of ARI.

The interception routines should work regardless of the channels being in
ARI or not. You set the interception channel variables to the dialplan
routine. The routine will execute when a connected line update passes
through.
https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines

You setup the CONNECTED_LINE_SEND_SUB and CONNECTED_LINE_SEND_SUB_ARGS
channel variables as if you were going to call the Gosub application:
same = n,Gosub(${CONNECTED_LINE_SEND_SUB}(${CONNECTED_LINE_SEND_SUB_ARGS})
Which is effectively what Asterisk does to call the interception routine.

Richard