<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br>It looks like the problem was not on the Freeswitch side.<br><br>I was unintentionally dropping the CANCELs generated by Freeswitch on the next SIP server and I thought unexpected behaviour was happening because voice mail answers.<br><br></div>So all I needed for these scenarios to work (even with voicemail) were:<br></div>- ignore_early_media<br></div>- group_key<br></div>- originate_timeout (just to hangup faster than the voicemail does)<br><br></div>Regards,<br></div>Stefan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 27, 2016 at 6:43 PM, Anonim Stefan <span dir="ltr">&lt;<a href="mailto:fanx07@gmail.com" target="_blank">fanx07@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,</p>
<p dir="ltr">Consider the originate serial calling scenario, done using the &quot;|&quot; sign, in a ESL python script. Consider that when one of the serial endpoints pick up,  I transfer to dialplan xml and bridge to a certain user. Now, consider the called endpoints in the serial group have voicemail activated and when they reject the invite, voice mail comes in and replies with _200 ok_ and does its thing.</p>
<p dir="ltr">The way I tackle this right now is I use group_key to wait for some user input. If no user dtmf input =&gt; voicemail.</p>
<p dir="ltr">The actual problem I am having is that if the first endpoint in the serial group rejects the call, the second endpoint in the serial group is never called because freeswitch saw that 200 ok and considers the user actually answered even though it was the voice mail. </p>
<p dir="ltr">Is there a way to make originate command try the second endpoint in the serial group, if the first one did not press dtmf group key in the right amount of time ? </p>
<p dir="ltr">Any suggestions how to tackle this further?!</p>
<p dir="ltr">Thanks, <br>
Stefan </p>
</blockquote></div><br></div>