<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 9/3/23 01:33, <a class="moz-txt-link-abbreviated" href="mailto:asterisk@phreaknet.org">asterisk@phreaknet.org</a>
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3f4d337e-631c-8185-1649-4a3ade3c87a5@phreaknet.org">Some
      architectural questions about the current incarnation of the
      builtin call pickup code... at some point I decided it was
      horribly deficient and wrote my own module that I typically use,
      but I wanted to see if I could get something to work for an
      environment just using simple building blocks.
      <br>
      <br>
      A slightly atypical use case I was toying with was picking up
      incoming calls arriving on FXO ports (chan_dahdi), but that aren't
      ringing any FXS stations. For example, the call could come in on
      FXO line 1 and ring FXS line 1, and the call ringing FXS line 1
      could be picked up, but I was trying to see if the original call
      to FXO 1 could be picked up without ringing any channels, i.e.
      pickup without ringing (which is maybe a bit contradictory). In
      the case of an FXO channel, it's already executing dialplan (so
      has a PBX), although it may still be in the "ring" state since it
      hasn't answered yet.
      <br>
      <br>
      In pickup.c, a channel is only eligible for pickup if there is no
      PBX running on it[1], so this seems to preclude the case above. As
      such, I have a couple questions, just to confirm I'm understanding
      this right:
      <br>
      <br>
       * Semantically, should the above scenario work with the builtin
      pickup
      <br>
         functionality, or is it by design that this case is excluded,
      e.g.
      <br>
         channels with a PBX but not yet answered (I'm guessing no,
      since how
      <br>
         would one distinguish between valid cases such as these, and
      most
      <br>
         any other? After all, to the core, it's a channel that's
      executing
      <br>
         dialplan)
      <br>
       * What would be the prototypical "Asterisk way" of doing the
      above
      <br>
         scenario? Something like ChannelRedirect() should work, but I
      mean
      <br>
         more within the bounds of the pickup construct (and maybe there
      <br>
         isn't any, just want to confirm I haven't missed something).
      Put
      <br>
         another way, how would you do the above, in the simplest way
      <br>
         possible? (high level, no code necessary)
      <br>
       * I'm thinking that one way to accomplish this given the way that
      <br>
         pickup is would be to have some kind of dummy "sink" channel
      driver,
      <br>
         e.g. something that can be called, but will never actually
      answer,
      <br>
         and can't do anything useful. This should make the above
      scenario
      <br>
         function without creating any further additional channels or
      ringing
      <br>
         any "real" endpoints. Local channels would not suffice, because
      they
      <br>
         begin executing dialplan immediately. The dummy channel driver
      <br>
         wouldn't do that, or really do anything, it would just be a
      valid
      <br>
         target for Dial() that would satisfy the properties expected by
      <br>
         pickup.c, to allow a channel currently ringing the dummy
      channel
      <br>
         driver to be picked up. A toy example:
      <br>
      <br>
      [from-fxo-port] ; Allow the incoming call from the FXO port to be
      picked up by any station in the same call group for up to 30
      seconds, go to voicemail otherwise.
      <br>
      exten => s,1,NoOp(Incoming call from ${CALLERID(all)}) ; after
      1 ring, chan_dahdi spawns PBX execution to handle the FXO port
      <br>
         same => n,Dial(WaitPickup/group1,30) ; not shown for
      simplicity, but would probably need to use a pre-dial subroutine
      to execute Set(CHANNEL(pickupgroup)=1) on the called channel, or
      the dummy driver would need to accept this and call
      ast_channel_callgroup_set in its _new callback.
      <br>
         same => n,NoOp(channel was not picked up within 30 seconds)
      <br>
         same => n,VoiceMail(1234)
      <br>
      <br>
      Let's ignore exactly how an end user is alerted to the fact there
      is an incoming call on the FXO port; that's not relevant to the
      situation here - for example, suppose there's an external ringer
      in parallel on the line.
      <br>
      <br>
      Any thoughts on doing something like this? I'm assuming there
      isn't such a channel driver already (since why would there be?),
      one would need to be written although it'd be fairly simple. Might
      there be a more elegant way of doing this that comes to mind?
      <br>
      <br>
      [1]
      <a class="moz-txt-link-freetext" href="https://github.com/asterisk/asterisk/blob/master/main/pickup.c#L79">https://github.com/asterisk/asterisk/blob/master/main/pickup.c#L79</a>
      <br>
      <br>
      <br>
    </blockquote>
    <p><font face="Liberation Sans">If you just want to avoid ringing
        extensions, sending the incoming call to a parking lot would
        suffice. To solve the "how to alert user" problem you can use
        ParkAndAnnounce() instead of Park(). Alternatively, AGI offers
        many options to DYI your own custom pickup.</font><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Dennis Buteyn
Xorcom Ltd</pre>
  </body>
</html>