Yup, the only way to do that is to modify the source.
The task of setting a channel variable to the parked slot is simple;
however, because the parkandannounce application is placing the call to
the "callee" to announce, it would need to have the logic of handling
the press 1 or 2 inside itself, ra
ParkAndAnnounce is kind of a misnomer; you don't necessarily need to
"announce".
I wholeheartedly agree that a variable (${PARKINGSLOT} perhaps?)
should be set on the return of ParkAndAnnounce, and that value should
find it's way into the "new" channel that is spawned by the
ParkAndAnnounce go
> I wholeheartedly agree that a variable (${PARKINGSLOT} perhaps?)
> should be set on the return of ParkAndAnnounce, and that value should
> find it's way into the "new" channel that is spawned by the
> ParkAndAnnounce goto-style call.
In the spirit of ${EXTEN} I would humbly suggest ${PARKEXTEN}
well each call is like an http request... you can't keep state from one to
the next like that.
bkw
On Wed, 4 Feb 2004, John Todd wrote:
>
> ParkAndAnnounce is kind of a misnomer; you don't necessarily need to
> "announce".
>
> I wholeheartedly agree that a variable (${PARKINGSLOT} perhaps?)
> sh
