<div dir="ltr"><div>This might work better in general if you use DTMF feature transfers to park instead of trying to use an on-phone transfer button to send the call to a park extension. Asterisk has internal logic to check an extension that you send a parked call to and will rely on res_parking functionality to actually perform the park and terminate the call if it's successful. Different SIP devices handle transfers in different ways and it can it can be hard to know how any of them will behave with certainty if you are relying on their features for doing your parking.<br></div><div><br></div><div>That said, I tried this using some Polycoms a few minutes ago to confirm how it behaves when using a typical SIP refer transfer and for me at least the call remained live after performing the transfer. The Polycom itself did have the original call in a held state, but that's a consequence of how the Polycom handles the call while performing a blind transfer.  If the parked calls fails, Asterisk should respond to the invite used for the transfer with a SIP BYE prior to sending a 200 OK unless you have something in your dialplan set up to answer the call ahead of that point. If a Polycom receives a BYE before connecting while attempting a blind transfer, it shouldn't disconnect from the original call. But I'm not sure what is in your configuration or the exact method you are using to transfer so it's hard to really nail anything down.<br></div><div><br></div><div>It's not really the kind of work I'm doing these days, but I'll provide advice if I can. Best of luck to you.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 26, 2018 at 4:32 PM Steve Sether <<a href="mailto:ssether@usinternet.com">ssether@usinternet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>I'm testing the behavior of when the parking lot is full.  I came
      across this post from Asterisk 12 beta, 5 years ago that describes
      the behavior I'm seeing.  <br>
    </p>
    <div class="m_2132627835542055534moz-forward-container">
      <p>I call ParkAndAnnounce, and when the lot is full  Asterisk
        drops the call, and sends a BYE to the caller.  This just
        doesn't work for us.<br>
      </p>
      <p>Is there any way to get around this problem?  Ideally what I'd
        like to happen is to retain the call, and defer to a context to
        deal with that situation.  Alternatively, is there a decent way
        to determine if a lot is full?  This isn't an ideal case, since
        you'd then have to deal with race conditions, but it's better
        than simply dropping the call when the lot is full.<br>
      </p>
      <p><br>
      </p>
      <p>The original discussion is here:<br>
      </p>
      <p><a class="m_2132627835542055534moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_pipermail_asterisk-2Ddev_2013-2DNovember_063565.html&d=DwMDaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=3BEHrW_8DZfxpAHt2Nr5LMIw6Odr6t7mD908OLBoX-c&e=" target="_blank">http://lists.digium.com/pipermail/asterisk-dev/2013-November/063565.html</a></p>
      <p><br>
      </p>
      <p>For context, this is the message:</p>
      <p><br>
      </p>
      <pre style="white-space:pre-wrap;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">><i>  
</i>><i> Out of morbid curiosity, could you test the same type of transfer  
</i>><i> against Asterisk 12's parking system? 
</i>><i>  
</i>><i> Also, is this a blind or attended transfer? As in, does the person  
</i>><i> transferring the call hear the parking failed message, and does that  
</i>><i> person then get hung up on, or is it the transferee the one that  
</i>><i> actually attempted parking and failed? 
</i>><i>  
</i>><i> --  
</i>><i> Jonathan R. Rose 
</i>><i> Digium, Inc. | Software Engineer 
</i>><i> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US 
</i>><i> direct +1 256 428 6139 
</i>><i>  
</i>

Jonathan, 

I was able to test this in Asterisk 12.0.0-beta1.

Parking works fine, but when parking lot is full, Asterisk sends SIP BYE to both parker and parkee (transferer, transferee) and the call is hung up. Compared to 18.23, Asterisk is left in a stable state though (in 1.8.23, I guess because the parking fails after the channels are masqueraded, Asterisk and phones turn unstable)

Test scenario:
123 called 125. 125 tried to park 123. Parking failed (parking lot is full). Asterisk sent both phones SIP BYE, call is hung up.
 
</pre>
    </div>
  </div>

-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=1QHEstuYPqNJZFqPhmLE1y8lB8IHxSTQkopS5hIcp5s&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=1QHEstuYPqNJZFqPhmLE1y8lB8IHxSTQkopS5hIcp5s&e=</a> --<br>
<br>
Astricon is coming up October 9-11!  Signup is available at: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.asterisk.org_community_astricon-2Duser-2Dconference&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=s12RV_nKi-FmKUEM2cwZ4eVwOau8LKRRW3w-yQmxNy8&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.asterisk.org_community_astricon-2Duser-2Dconference&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=s12RV_nKi-FmKUEM2cwZ4eVwOau8LKRRW3w-yQmxNy8&e=</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=_zvbJSEyBW5-WqKuWULB7AbcLeZjrTzhGs6H62UEOE0&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E&s=_zvbJSEyBW5-WqKuWULB7AbcLeZjrTzhGs6H62UEOE0&e=</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><b>Jonathan R. Rose<br></b><span><span>Senior Systems Engineer<br><br></span></span></div>Emergency CallWorks<br></div>Motorola Solutions<br><br></div><div>email: <a href="mailto:jonathan.rose@motorolasolutions.com" target="_blank">jonathan.rose@motorolasolutions.com</a><br></div></div></div></div>