<p>B.H.</p>
<p>Thanks for your response</p>
<p>On Aug 23, 2013 11:21 AM, "Gareth Blades" <<a href="mailto:mailinglist%2Basterisk@dns99.co.uk">mailinglist+asterisk@dns99.co.uk</a>> wrote:<br>
><br>
> On 22/08/13 15:43, Mordechay Kaganer wrote:<br>
>><br>
>> B.H.<br>
>><br>
>> Hello, i'm using AMI Originate action (with async=true) to send outgoing calls to a SIP trunk (using asterisk-java library to connect to AMI).<br>
>><br>
>> The problem is that in case of failed originate, OriginateResponse event is returning only the reason code which is sometimes not sufficient to determine the real cause of failure. Also, there's no way to link between the channel that was trying to dial and failed and the original Originate request, because OriginateResponse is issued only after the failed channel was hang up. Only successful OriginateResponse will contain the unique id of the established channel.<br>
>><br>
>> Is there any way that my AMI application can get the original SIP response of the failed Originate action?<br>
>><br>
>> I'm using Asterisk 1.8.22 and slightly tweaked asterisk-java (<a href="https://blogs.reucon.com/asterisk-java/">https://blogs.reucon.com/asterisk-java/</a>) 1.0.0.<br>
>><br>
><br>
> You could dial a local channel instead and have that then go on and dial the destination. You will then be able to retrieve the sip response using something like :-<br>
><br>
> [localdial]<br>
> exten => _X.,1,Set(ddi=${CUT(EXTEN,,1)})<br>
> exten => _X.,n,Set(carrier=${CUT(EXTEN,,2)})<br>
> exten => _X.,n,Set(dialtime=${EPOCH})<br>
> exten => _X.,n,Set(_MASTERCHANNEL=${CHANNEL})<br>
> exten => _X.,n,Dial(SIP/${ddi}@${carrier})<br>
> exten => _X.,n,Set(SIPcause=${MASTER_CHANNEL(HASH(SIP_CAUSE,${CDR(dstchannel)}))}, Responsetime=$[${EPOCH}-${dialtime}])<br>
> exten => _X.,n,Set(SIPcode=${CUT(SIPcause," ",2)})<br>
><br>
> However you will need to set "storesipcause=yes" in your sip.conf for this to work. It is known to have a performance hit.</p>
<p>In my experience with local channels, they cause a huge performance problems, even without sipstorecause. We are dialing on about 100 channels in parallel and looks like this will kill my CPU :-)</p>
<p>><br>
> A better way would be to upgrade Asterisk and use hangup handlers. The documentation on how to do this in Asterisk 11 is poor and often wrong. I have written a blog about how we set it up as we use the feature all the time.<br>
> <a href="http://gblades.blogspot.co.uk/2013/07/how-to-get-sip-response-code-in.html">http://gblades.blogspot.co.uk/2013/07/how-to-get-sip-response-code-in.html</a><br>
><br>
></p>
<p>This looks really promising... Thank you very much. Just I hope upgrading to 11 wouldn't break something in our setup.</p>
<p>There's still a problem with how to link a failed dialout channel with a specific originate action from AMI, but I think I can pass the originate action id as a channel variable and then return it back to my app using AGI from the hungup handler.</p>
<p>Thanks for the help!</p>
<p>> --<br>
> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br>
> New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
> <a href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a><br>
><br>
> asterisk-users mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</p>