[new-feature]: chan_dahdi: Allow waitfordialtone to be specified per call #472
Assignees
Labels
Comments
InterLinked1
added a commit
to InterLinked1/asterisk
that referenced
this issue
Dec 2, 2023
The existing "waitfordialtone" setting in chan_dahdi.conf applies permanently to a specific channel, regardless of how it is being used. This rather restrictively prevents a system from simultaneously being able to pick free lines for outgoing calls while also allowing barge-in to a trunk by some other arrangement. This allows specifying "waitfordialtone" using the CHANNEL function for only the next call that will be placed, allowing significantly more flexibility in the use of trunk interfaces. Resolves: asterisk#472 UserNote: "waitfordialtone" may now be specified for DAHDI trunk channels on a per-call basis using the CHANNEL function.
jcolp
added
support-level-core
asterisk-org-access-app bot
pushed a commit
that referenced
this issue
Mar 20, 2024
The existing "waitfordialtone" setting in chan_dahdi.conf applies permanently to a specific channel, regardless of how it is being used. This rather restrictively prevents a system from simultaneously being able to pick free lines for outgoing calls while also allowing barge-in to a trunk by some other arrangement. This allows specifying "waitfordialtone" using the CHANNEL function for only the next call that will be placed, allowing significantly more flexibility in the use of trunk interfaces. Resolves: #472 UserNote: "waitfordialtone" may now be specified for DAHDI trunk channels on a per-call basis using the CHANNEL function.
asterisk-org-access-app bot
pushed a commit
that referenced
this issue
Mar 20, 2024
The existing "waitfordialtone" setting in chan_dahdi.conf applies permanently to a specific channel, regardless of how it is being used. This rather restrictively prevents a system from simultaneously being able to pick free lines for outgoing calls while also allowing barge-in to a trunk by some other arrangement. This allows specifying "waitfordialtone" using the CHANNEL function for only the next call that will be placed, allowing significantly more flexibility in the use of trunk interfaces. Resolves: #472 UserNote: "waitfordialtone" may now be specified for DAHDI trunk channels on a per-call basis using the CHANNEL function.
asterisk-org-access-app bot
pushed a commit
that referenced
this issue
Mar 20, 2024
The existing "waitfordialtone" setting in chan_dahdi.conf applies permanently to a specific channel, regardless of how it is being used. This rather restrictively prevents a system from simultaneously being able to pick free lines for outgoing calls while also allowing barge-in to a trunk by some other arrangement. This allows specifying "waitfordialtone" using the CHANNEL function for only the next call that will be placed, allowing significantly more flexibility in the use of trunk interfaces. Resolves: #472 UserNote: "waitfordialtone" may now be specified for DAHDI trunk channels on a per-call basis using the CHANNEL function.
asterisk-org-access-app bot
pushed a commit
that referenced
this issue
Mar 20, 2024
The existing "waitfordialtone" setting in chan_dahdi.conf applies permanently to a specific channel, regardless of how it is being used. This rather restrictively prevents a system from simultaneously being able to pick free lines for outgoing calls while also allowing barge-in to a trunk by some other arrangement. This allows specifying "waitfordialtone" using the CHANNEL function for only the next call that will be placed, allowing significantly more flexibility in the use of trunk interfaces. Resolves: #472 UserNote: "waitfordialtone" may now be specified for DAHDI trunk channels on a per-call basis using the CHANNEL function.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Description
chan_dahdi currently has a
waitfordialtonesetting that will wait for audible dial tone after seizing a trunk to ensure it is free for placing an outbound call. However, this is a permanent setting which prevents "barging in" on an ongoing call by dialing the FXO channel directly, effectively preventing people from simultaneously doing two reasonable things, forcing them to choose one behavior or the other.For example, more reasonable behavior (typical of how many hardware PBXs behave) is to allow barging into a trunk if the code for that trunk is explicitly dialed, but skipping that trunk if it's already in use when placing a call using a trunk group.
This allows the
waitfordialtonesetting to be invoked on a per-call basis, so that people can leave the global setting unset and only specifywaitfordialtonefor invocations where this is desired, as opposed to all of them.The text was updated successfully, but these errors were encountered: