<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 30 Oct 2018 at 22:20, Stephen Davies <<a href="mailto:stephen.l.davies@gmail.com">stephen.l.davies@gmail.com</a>> wrote:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div></div></blockquote><div><br></div><div>Ah - my apologies, I see its actually documented:</div><div><br></div></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The option blocks all redirecting updates since they should only happen 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.</blockquote></div></blockquote><div class="gmail_quote"><div><br></div><div>So its intended to work the way it works.</div><div><br></div><div>So its then important to understand how to use the interception macros or some equivalent in the context of ARI.<br></div><div><br></div><div>Thanks,</div><div>Steve</div><div><br></div></div></div>