[asterisk-users] documentation of DAHDI dial options

[Klaus Darilion]

Hi!

I am searching for the description of the available dialstrin options
for the DAHDI channel (and also other channel types).

I am not looking for outdated voip-info links, but for the authoritative
source, e.g. something like "core show application Dial"

Does such thing exists?

thanks
Klaus

[Jared Smith]

Post by Klaus Darilion
I am searching for the description of the available dialstrin options
for the DAHDI channel (and also other channel types).
I am not looking for outdated voip-info links, but for the authoritative
source, e.g. something like "core show application Dial"
Does such thing exists?

I don't think that such a thing exists. The only ones I'm aware of are:

1) Channel Groups.

DAHDI/g1/5551212 dials 5551212 on the first available channel in group
one, searching from lowest to highest

DAHDI/G1/5551212 dials 5551212 on the first available channel in group
one, searching from highest to lowest

DAHDI/r1/5551212 dials 5551212 on the first available channel in group
one, going in round-robin fashion (and remembering where it last left
off), searching from lowest to highest

DAHDI/R1/5551212 dials 5551212 on the first available channel in group
one, searching in round-robin fashion from highest to lowest.

2) Distinctive ring

DAHDI/4r1 dials channel 4 (presumably an FXS channel), and uses
distinctive ring style one. If I recall, there are four different
distinctive ring styles... so you could replace r1 with r2, r3, or r4.

3) Answer confirmation

DAHDI/1c/5551212 tells Asterisk to dial 5551212 on DAHDI channel 1, and
not consider the call answered until the called party presses #. This
is useful because of the way analog signaling works. Without this
setting, Asterisk considers any outbound analog call on an FXO port
answered just as soon as it has been dialed.

4) Digital calls

DAHDI/1d/5551212 tells Asterisk to dial 5551212 on DAHDI channel 1, and
that it's a digital call. If I remember correctly, this is used for
ISDN calls to set the bearer capability.

I've taken a quick look in channels/chan_dahdi.c in TRUNK, and it seems
to match up with my understanding, as I didn't see any other options
stand out. While poking around in there, I found the following comment:

/*
* data is ---v
* Dial(DAHDI/pseudo[/extension])
* Dial(DAHDI/<channel#>[c|r<cadance#>|d][/extension])
* Dial(DAHDI/(g|G|r|R)<group#(0-63)>[c|r<cadance#>|d][/extension])
*
* g - channel group allocation search forward
* G - channel group allocation search backward
* r - channel group allocation round robin search forward
* R - channel group allocation round robin search backward
*
* c - Wait for DTMF digit to confirm answer
* r<cadance#> - Set distintive ring cadance number
* d - Force bearer capability for ISDN/SS7 call to digital.
*/

That's probably as definitive an answer as you're going to get.

[Karl Fife]

I'm using Fax For Asterisk, and trying to optimize the user experience while
ROUTING faxes based on the Transmitting Station ID [sic] (NOT the CALLERID).

Specifically I'm trying to eliminate end-user confusion as "that fifty page
fax" spools to a file, creating a significant delay, leaving the user to
wonder "why am I not getting my fax--they said it's currently sending". A
better user-experience would be to begin TX'ing the fax (at the same or
slower speed than RX) after a page or two has been spooled as a buffer.

If I'm using SendFax from the dialplan it appears that I would need to spool
an entire incoming fax to file (to completion) before I could route said fax
based on the Transmitting Station ID

However if I were to drive the fax process from manager rather than from the
dialplan, would the TSID be available for read before RX completion, AND
(equally important) would sendfax even tolerate sending a fax from an
still-spooling RX file? In other words, does the application require that
the spool file be complete and closed before it would allow you to begin
paying it out 'from the top'?


Thanks
-Karl

[Danny Nicholas]

Receipt of the fax could be handled in the manner you describe using
something like Ghostscript to parse the partial file into pages as it came
in. Sending the file is pretty much an "all or none" proposition unless you
did something funky like splitting the file into chunks and sending in
consecutive sessions. I'm pretty sure FFA doesn't let you say send 1&2&3
etc.

-----Original Message-----
From: asterisk-users-***@lists.digium.com
[mailto:asterisk-users-***@lists.digium.com] On Behalf Of Karl Fife
Sent: Tuesday, July 07, 2009 10:02 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] Fax for Asterisk - Fax routing based on TSID

I'm using Fax For Asterisk, and trying to optimize the user experience while

ROUTING faxes based on the Transmitting Station ID [sic] (NOT the CALLERID).

Specifically I'm trying to eliminate end-user confusion as "that fifty page
fax" spools to a file, creating a significant delay, leaving the user to
wonder "why am I not getting my fax--they said it's currently sending". A
better user-experience would be to begin TX'ing the fax (at the same or
slower speed than RX) after a page or two has been spooled as a buffer.

If I'm using SendFax from the dialplan it appears that I would need to spool

an entire incoming fax to file (to completion) before I could route said fax

based on the Transmitting Station ID

However if I were to drive the fax process from manager rather than from the

dialplan, would the TSID be available for read before RX completion, AND
(equally important) would sendfax even tolerate sending a fax from an
still-spooling RX file? In other words, does the application require that
the spool file be complete and closed before it would allow you to begin
paying it out 'from the top'?


Thanks
-Karl


_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[Kevin P. Fleming]

Post by Karl Fife
However if I were to drive the fax process from manager rather than from the
dialplan, would the TSID be available for read before RX completion, AND
(equally important) would sendfax even tolerate sending a fax from an
still-spooling RX file? In other words, does the application require that
the spool file be complete and closed before it would allow you to begin
paying it out 'from the top'?

I don't think that the current FFA applications will do what you want.
Even if you could somehow manage this, any delay in the receiving
process could cause it to get 'behind' the sending process, which would
then abort due to an incomplete file. That's even assuming that the
SendFAX application will accept an incomplete TIFF/F file in the first
place :-)

Even with FAX gateway support you wouldn't be able to achieve this,
because the gateway outbound link would be setup before the TSID is
received.

What might be possible is to have a page-per-file mode, so that as each
page is received it is stored in a separate file; you could then watch
for 'received page' events and transmit the pages that had been received
up to that point. I'll do a bit of research to see if this is possible.

[Olivier]

Post by Karl Fife
I'm using Fax For Asterisk, and trying to optimize the user experience while
ROUTING faxes based on the Transmitting Station ID [sic] (NOT the CALLERID).

Please, allow me to ask what is this Transmitting Station ID ?

Post by Karl Fife
Thanks
-Karl
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users

[Doug Lytle]

Post by Olivier
Please, allow me to ask what is this Transmitting Station ID ?

Google is you friend:

http://encyclopedia.thefreedictionary.com/Transmitting+Subscriber+Identification

Doug

[Olivier]

Post by Doug Lytle

Post by Olivier
Please, allow me to ask what is this Transmitting Station ID ?

http://encyclopedia.thefreedictionary.com/Transmitting+Subscriber+Identification

Thanks !
I still have to improve my googling !

Post by Doug Lytle
Doug
--
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety."
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users

[Olivier]

Post by Jared Smith

Post by Klaus Darilion
I am searching for the description of the available dialstrin options
for the DAHDI channel (and also other channel types).
I am not looking for outdated voip-info links, but for the authoritative
source, e.g. something like "core show application Dial"
Does such thing exists?

1) Channel Groups.
DAHDI/g1/5551212 dials 5551212 on the first available channel in group
one, searching from lowest to highest
DAHDI/G1/5551212 dials 5551212 on the first available channel in group
one, searching from highest to lowest
DAHDI/r1/5551212 dials 5551212 on the first available channel in group
one, going in round-robin fashion (and remembering where it last left
off), searching from lowest to highest
DAHDI/R1/5551212 dials 5551212 on the first available channel in group
one, searching in round-robin fashion from highest to lowest.
2) Distinctive ring
DAHDI/4r1 dials channel 4 (presumably an FXS channel), and uses
distinctive ring style one. If I recall, there are four different
distinctive ring styles... so you could replace r1 with r2, r3, or r4.
3) Answer confirmation
DAHDI/1c/5551212 tells Asterisk to dial 5551212 on DAHDI channel 1, and
not consider the call answered until the called party presses #. This
is useful because of the way analog signaling works. Without this
setting, Asterisk considers any outbound analog call on an FXO port
answered just as soon as it has been dialed.
4) Digital calls
DAHDI/1d/5551212 tells Asterisk to dial 5551212 on DAHDI channel 1, and
that it's a digital call. If I remember correctly, this is used for
ISDN calls to set the bearer capability.
I've taken a quick look in channels/chan_dahdi.c in TRUNK, and it seems
to match up with my understanding, as I didn't see any other options
/*
* data is ---v
* Dial(DAHDI/pseudo[/extension])
* Dial(DAHDI/<channel#>[c|r<cadance#>|d][/extension])
* Dial(DAHDI/(g|G|r|R)<group#(0-63)>[c|r<cadance#>|d][/extension])
*
* g - channel group allocation search forward
* G - channel group allocation search backward
* r - channel group allocation round robin search forward
* R - channel group allocation round robin search backward
*
* c - Wait for DTMF digit to confirm answer
* r<cadance#> - Set distintive ring cadance number
* d - Force bearer capability for ISDN/SS7 call to digital.
*/
That's probably as definitive an answer as you're going to get.

What is this was commented such as it could be added to a "core show
application Dial" ?

Post by Jared Smith
--
Jared Smith
Training Manager
Digium, Inc.
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users

[Klaus Darilion]

Post by Jared Smith

Post by Klaus Darilion
I am searching for the description of the available dialstrin options
for the DAHDI channel (and also other channel types).
I am not looking for outdated voip-info links, but for the authoritative
source, e.g. something like "core show application Dial"
Does such thing exists?

1) Channel Groups.
DAHDI/g1/5551212 dials 5551212 on the first available channel in group
one, searching from lowest to highest
DAHDI/G1/5551212 dials 5551212 on the first available channel in group
one, searching from highest to lowest
DAHDI/r1/5551212 dials 5551212 on the first available channel in group
one, going in round-robin fashion (and remembering where it last left
off), searching from lowest to highest
DAHDI/R1/5551212 dials 5551212 on the first available channel in group
one, searching in round-robin fashion from highest to lowest.
2) Distinctive ring
DAHDI/4r1 dials channel 4 (presumably an FXS channel), and uses
distinctive ring style one. If I recall, there are four different
distinctive ring styles... so you could replace r1 with r2, r3, or r4.
3) Answer confirmation
DAHDI/1c/5551212 tells Asterisk to dial 5551212 on DAHDI channel 1, and
not consider the call answered until the called party presses #. This
is useful because of the way analog signaling works. Without this
setting, Asterisk considers any outbound analog call on an FXO port
answered just as soon as it has been dialed.
4) Digital calls
DAHDI/1d/5551212 tells Asterisk to dial 5551212 on DAHDI channel 1, and
that it's a digital call. If I remember correctly, this is used for
ISDN calls to set the bearer capability.
I've taken a quick look in channels/chan_dahdi.c in TRUNK, and it seems
to match up with my understanding, as I didn't see any other options
/*
* data is ---v
* Dial(DAHDI/pseudo[/extension])
* Dial(DAHDI/<channel#>[c|r<cadance#>|d][/extension])
* Dial(DAHDI/(g|G|r|R)<group#(0-63)>[c|r<cadance#>|d][/extension])
*
* g - channel group allocation search forward
* G - channel group allocation search backward
* r - channel group allocation round robin search forward
* R - channel group allocation round robin search backward
*
* c - Wait for DTMF digit to confirm answer
* r<cadance#> - Set distintive ring cadance number
* d - Force bearer capability for ISDN/SS7 call to digital.
*/
That's probably as definitive an answer as you're going to get.

Thanks, great. So now we have what I was looking for.

Now we need a place to make this documentation public. I wonder what
could be a place for that?

IMO it would be great if the documentation would be inside Asterisk.
Maybe it could be added to "core show channeltype dahdi". What do you
think? Otherwise this information is again lost, and voip-info pages are
always outdated.

regards
klaus