Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: Yes. I saw the message and the required addition in the sip.conf. The problem is that if I set it to 72, other terminating gateways that support 400 or more would also be limited to 72. This is incorrect. First, you would not set it to 72, since the endpoint is already telling you 72; you would set it to something higher. Second, as the documentation states (and my email stated), this a minimum threshold. It does not override the value provided by the endpoint unless the provided value is *lower*. All of this you would know if you had already tried it, which probably would have taken less time than writing the two emails about it have taken :-) What doesn't make sense is Asterisk's commission. Why doesn't it simply pass/use whatever it gets without cutting the values? It looks like it's a bug. It is not a bug. Asterisk has to deconstruct incoming UDPTL frames when they are received, pass them through a bridge, and then construct new ones on the outbound side. To do this, it has to have knowledge of what the maximum IFP size each endpoint can receive is, and compute a reasonable T38FaxMaxDatagram value to tell the *other* endpoint (taking into account the error correction mode(s) in use) so that when it receives a UDPTL frame from endpoint A it can be reasonably assured it will be able to forward it to endpoint B without violating endpoint B's max datagram size... but when endpoint B has told Asterisk a ludicrous max datagram size, it must be overridden somewhere to allow FAXes any reasonable chance of working. Alternatively, I could (had I known how ;-)) set this ATA not to relay the RTP via Asterisk, in which case maybe Asterisk would leave the values unchanged. When I use another port on this ATA from the same location to the same destination without passing through the Asterisk, the faxes go through. How should I define this peer in sip.conf so that Asterisk wouldn't relay the RTP for it? T.38 FAX can use RTP, but almost never does; in all of the cases you are dealing with, it is using UDPTL for media transport, not RTP. Asterisk does not yet support direct UDPTL media between endpoints, so that's not an option for you. That's not necessary, though, because clearly when you tell those two endpoints to talk directly to each other, the one that receives 'T38FaxMaxDatagram: 72' is *ignoring* that restriction and sending larger packets... it has to, or the FAX would fail. Asterisk doesn't do that automatically, for safety's sake, it tells the administrator when this problem is occurring and how to overcome it. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: This is the reINVITE SDP received from the SIP Proxy: --- Content-Type: application/sdp Content-Length: 353 v=0 o=root 30427 30428 IN IP4 194.98.xxx.xxx s=session c=IN IP4 194.98.xxx.xxx t=0 0 m=image 17548 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:72 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy --- This is probably originating from a Cisco gateway. Cisco gateways generate T.38 SDPs that do not conform to the T.38 recommendation in one very obvious (and painful) way: they tell us that they can only accept 72 byte packets (T38FaxMaxDatagram), when in fact they can accept packets much larger than that. When you notice that they are also requesting that we use t38UDPRedundancy for error correction, that means that the maximum IFP (single FAX protocol packet) we can include in a UDPTL datagram is around 30 bytes, since we'd need to have room for two of them and a bit of overhead. 30 bytes is a ridiculously small limit for IFPs, and does not allow successful FAXing at any possible bit rate (except for 2400 bits per second using 10 millisecond IFPs, but no FAX stack would do that). I was having similar issues, trying Asterisk 1.6.1.12-rc1 resolved it. http://www.mail-archive.com/asterisk-users@lists.digium.com/msg234015.html Good luck. JR -- JR Richardson Engineering for the Masses ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Hello, We upgraded the Asterisk to 1.6.1.11. Now, there's no RTP reINVITE, but the datagram handling of Asterisk is strange. Basically, it takes a commission from both ends, and ends up overflowing: Reminder, we're dealing in this example with a passthrough, where we have an ATA device connected to Asterisk in the same LAN, the Asterisk is registered to a remote SIP Proxy server and behind it, a Fax server. This is the reINVITE SDP received from the SIP Proxy: --- Content-Type: application/sdp Content-Length: 353 v=0 o=root 30427 30428 IN IP4 194.98.xxx.xxx s=session c=IN IP4 194.98.xxx.xxx t=0 0 m=image 17548 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:72 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy --- Asterisk sends this reINVITE SDP to the ATA device (notice that the datagram was reduced by 2): --- Content-Type: application/sdp Content-Length: 269 v=0 o=root 31812 318120001 IN IP4 192.168.2.10 s=Asterisk PBX 1.6.1.11 c=IN IP4 192.168.2.10 t=0 0 m=image 4427 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:70 a=T38FaxUdpEC:t38UDPRedundancy --- Then, it gets OK SDP from the ATA with the same settings it suggested: --- Content-Type: application/sdp Content-Length: 275 v=0 o=101 01 02 IN IP4 192.168.2.11 s=A conversation c=IN IP4 192.168.2.11 t=0 0 m=image 9100 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:70 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv --- But, when it sends the OK SDP to the remote end, it lowers the datagram again: --- Content-Type: application/sdp Content-Length: 275 v=0 o=root 936220937 936220938 IN IP4 xxx.xxx.xxx.xxx s=Asterisk PBX 1.6.1.11 c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=image 4650 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:65 a=T38FaxUdpEC:t38UDPRedundancy --- Then, when the ATA device sends T.38 packets, it freaks outs: --- pbx*CLI Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 86) [Dec 15 12:38:05] WARNING[5262]: udptl.c:997 ast_udptl_write: UDPTL asked to send 77 bytes of IFP when far end only prepared to accept 12 bytes; data loss may occur. You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. [Dec 15 12:38:05] ERROR[5262]: udptl.c:291 encode_open_type: Buffer overflow detected (77 + 3 72) [Dec 15 12:38:05] NOTICE[5262]: udptl.c:1010 ast_udptl_write: UDPTL Transmission error to 194.98.xxx.xxx:17548: Message too long Sent UDPTL packet to 194.98.xxx.xxx:17548 (type 0, seq 35, len -1) pbx*CLI Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 162) [Dec 15 12:38:05] WARNING[5262]: udptl.c:997 ast_udptl_write: UDPTL asked to send 77 bytes of IFP when far end only prepared to accept 12 bytes; data loss may occur. You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. [Dec 15 12:38:05] ERROR[5262]: udptl.c:291 encode_open_type: Buffer overflow detected (77 + 3 72) [Dec 15 12:38:05] NOTICE[5262]: udptl.c:1010 ast_udptl_write: UDPTL Transmission error to 194.98.xxx.xxx:17548: Message too long --- Thank you for your kind assistance and support. Regards, Andreas Original Message Subject: Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9 From: Cyprus VoIP voi...@gmail.com To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Date: Friday, 04 December, 2009 18:21:59 It's probably because you are using 1.6.1.9; that release (and older) had a 'feature' that allowed automatic switching back to audio from T.38 if one of the endpoints sent an audio packet. It turns out that wasn't a good idea, and it's been removed... but in later versions. You'll have to update to the latest release to get that fixed. Will do. Thanks for the explanation. ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: This is the reINVITE SDP received from the SIP Proxy: --- Content-Type: application/sdp Content-Length: 353 v=0 o=root 30427 30428 IN IP4 194.98.xxx.xxx s=session c=IN IP4 194.98.xxx.xxx t=0 0 m=image 17548 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:72 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy --- This is probably originating from a Cisco gateway. Cisco gateways generate T.38 SDPs that do not conform to the T.38 recommendation in one very obvious (and painful) way: they tell us that they can only accept 72 byte packets (T38FaxMaxDatagram), when in fact they can accept packets much larger than that. When you notice that they are also requesting that we use t38UDPRedundancy for error correction, that means that the maximum IFP (single FAX protocol packet) we can include in a UDPTL datagram is around 30 bytes, since we'd need to have room for two of them and a bit of overhead. 30 bytes is a ridiculously small limit for IFPs, and does not allow successful FAXing at any possible bit rate (except for 2400 bits per second using 10 millisecond IFPs, but no FAX stack would do that). There is code in Asterisk already to deal with this problem, however... see below. pbx*CLI Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 86) [Dec 15 12:38:05] WARNING[5262]: udptl.c:997 ast_udptl_write: UDPTL asked to send 77 bytes of IFP when far end only prepared to accept 12 bytes; data loss may occur. You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. Have you followed these instructions? The message is fairly clear in describing the problem, and the description of how and why this is needed is spelled out in the sip.conf.sample file in the configs directory of the source tree. Setting a lower limit for the max datagram value used when communicating with this peer (and others like it that generate incorrect T38FaxMaxDatagram values) will resolve this problem. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: This is the reINVITE SDP received from the SIP Proxy: --- Content-Type: application/sdp Content-Length: 353 v=0 o=root 30427 30428 IN IP4 194.98.xxx.xxx s=session c=IN IP4 194.98.xxx.xxx t=0 0 m=image 17548 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:72 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy --- This is probably originating from a Cisco gateway. Cisco gateways generate T.38 SDPs that do not conform to the T.38 recommendation in one very obvious (and painful) way: they tell us that they can only accept 72 byte packets (T38FaxMaxDatagram), when in fact they can accept packets much larger than that. When you notice that they are also requesting that we use t38UDPRedundancy for error correction, that means that the maximum IFP (single FAX protocol packet) we can include in a UDPTL datagram is around 30 bytes, since we'd need to have room for two of them and a bit of overhead. 30 bytes is a ridiculously small limit for IFPs, and does not allow successful FAXing at any possible bit rate (except for 2400 bits per second using 10 millisecond IFPs, but no FAX stack would do that). There is code in Asterisk already to deal with this problem, however... see below. pbx*CLI Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 86) [Dec 15 12:38:05] WARNING[5262]: udptl.c:997 ast_udptl_write: UDPTL asked to send 77 bytes of IFP when far end only prepared to accept 12 bytes; data loss may occur. You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. Have you followed these instructions? The message is fairly clear in describing the problem, and the description of how and why this is needed is spelled out in the sip.conf.sample file in the configs directory of the source tree. Setting a lower limit for the max datagram value used when communicating with this peer (and others like it that generate incorrect T38FaxMaxDatagram values) will resolve this problem. Hi, Yes. I saw the message and the required addition in the sip.conf. The problem is that if I set it to 72, other terminating gateways that support 400 or more would also be limited to 72. What doesn't make sense is Asterisk's commission. Why doesn't it simply pass/use whatever it gets without cutting the values? It looks like it's a bug. Alternatively, I could (had I known how ;-)) set this ATA not to relay the RTP via Asterisk, in which case maybe Asterisk would leave the values unchanged. When I use another port on this ATA from the same location to the same destination without passing through the Asterisk, the faxes go through. How should I define this peer in sip.conf so that Asterisk wouldn't relay the RTP for it? Thanks, Andreas ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: Thank you for your answer. The 'internal extension' is indeed a T.38 capable device that works perfectly when connected directly to the Proxy/ITSP. As you said, the key to debugging/resolving this issue is the logger. I wasn't aware of this file. this is what I have there: ... ;debug = debug console = notice,warning,error ;console = notice,warning,error,debug messages = notice,warning,error ;full = notice,warning,error,debug,verbose ... Should I change the console... line or uncomment the ;full... line? Either one is fine; using 'full' is actually a bit better, because the color highlighting done on the console sometimes makes console captures hard to read. Hi, So, I enabled the full logger, and the strange thing I see is this message: Got T.38 Re-invite without audio. Keeping RTP active during T.38 session It seems that this might be the reason Asterisk initiates a reINVITE with voice codecs, after connecting the 2 parties. Is there a way to disable that action, or do we need to add T.38 somehow to the list of codecs? I followed the instructions on the default sip.conf to include the line t38pt_udptl=yes,redundancy in the general section and in each of the parties. Thanks. ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Set 'canreinvite=no' on all applicable peers? I tried with yes and no. No difference. I'm almost certain it's related to the Keeping RTP active during T.38 session issue. ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: So, I enabled the full logger, and the strange thing I see is this message: Got T.38 Re-invite without audio. Keeping RTP active during T.38 session It seems that this might be the reason Asterisk initiates a reINVITE with voice codecs, after connecting the 2 parties. Sorry, that's not the issue. That just means that chan_sip didn't destroy the internal RTP structures used for the audio part of the call when the call switched to T.38, which is only an optimization so we don't have to recreate them if the call switches back. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: So, I enabled the full logger, and the strange thing I see is this message: Got T.38 Re-invite without audio. Keeping RTP active during T.38 session It seems that this might be the reason Asterisk initiates a reINVITE with voice codecs, after connecting the 2 parties. Sorry, that's not the issue. That just means that chan_sip didn't destroy the internal RTP structures used for the audio part of the call when the call switched to T.38, which is only an optimization so we don't have to recreate them if the call switches back. Hi Kevin, Thank you for your support. If it's not related, why does Asterisk send again INVITE messages to both parties? How can this be prevented? I don't see more debug data prior to the new INVITE. Thanks. ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: If it's not related, why does Asterisk send again INVITE messages to both parties? How can this be prevented? I don't see more debug data prior to the new INVITE. It's probably because you are using 1.6.1.9; that release (and older) had a 'feature' that allowed automatic switching back to audio from T.38 if one of the endpoints sent an audio packet. It turns out that wasn't a good idea, and it's been removed... but in later versions. You'll have to update to the latest release to get that fixed. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
It's probably because you are using 1.6.1.9; that release (and older) had a 'feature' that allowed automatic switching back to audio from T.38 if one of the endpoints sent an audio packet. It turns out that wasn't a good idea, and it's been removed... but in later versions. You'll have to update to the latest release to get that fixed. Will do. Thanks for the explanation. ___ -- 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
[asterisk-users] Fax throughput - Asterisk 1.6.1.9
Hello, We are trying to send faxes by T.38 protocol to a remote SIP proxy from a local extension. The local extension sends the INVITE, Asterisk sends the call to the Proxy the call is connected with a regular audio codec. After a few seconds the remote proxy sends an INVITE with UDPTL and the Asterisk sends it to the local extension and it's accepted, but (here the problem starts) just after sending the OK with the proper SDP to the remote Proxy, the Asterisk initiates a new INVITE to the local extension and remote Proxy, with the normal audio codecs again. We set t38pt_udptl=yes in sip.conf and allowed all the codecs to the local extension and remote Proxy, but it still forces the call to go back to a voice call. Any idea why it happens and how to debug it? We set verbose and debug to 20, but no internal info is provided to get a clear understanding on Asterisk's thoughts during that process. Thank you in advance for your assistance, Andreas ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: We set t38pt_udptl=yes in sip.conf and allowed all the codecs to the local extension and remote Proxy, but it still forces the call to go back to a voice call. Define 'internal extension'. Is this a T.38-capable device? If not, Asterisk doesn't support TDM-to-T.38 FAX relay (yet). If it is, then the path to resolving this problem is to collect a complete console log of the failing call, including 'core set debug 10', 'core set verbose 10' and 'sip set debug on' (and please ensure that all five logger levels are enabled for the 'console' log channel in logger.conf). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: We set t38pt_udptl=yes in sip.conf and allowed all the codecs to the local extension and remote Proxy, but it still forces the call to go back to a voice call. That's correct behavior if T.38 cannot autonegotiate. What happens in the reverse direction, trying to send faxes from your mysterious proxy to asterisk? ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
We set t38pt_udptl=yes in sip.conf and allowed all the codecs to the local extension and remote Proxy, but it still forces the call to go back to a voice call. Define 'internal extension'. Is this a T.38-capable device? If not, Asterisk doesn't support TDM-to-T.38 FAX relay (yet). If it is, then the path to resolving this problem is to collect a complete console log of the failing call, including 'core set debug 10', 'core set verbose 10' and 'sip set debug on' (and please ensure that all five logger levels are enabled for the 'console' log channel in logger.conf). Hi Kevin, Thank you for your answer. The 'internal extension' is indeed a T.38 capable device that works perfectly when connected directly to the Proxy/ITSP. As you said, the key to debugging/resolving this issue is the logger. I wasn't aware of this file. this is what I have there: ... ;debug = debug console = notice,warning,error ;console = notice,warning,error,debug messages = notice,warning,error ;full = notice,warning,error,debug,verbose ... Should I change the console... line or uncomment the ;full... line? Regards, Andreas ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Cyprus VoIP wrote: Thank you for your answer. The 'internal extension' is indeed a T.38 capable device that works perfectly when connected directly to the Proxy/ITSP. As you said, the key to debugging/resolving this issue is the logger. I wasn't aware of this file. this is what I have there: ... ;debug = debug console = notice,warning,error ;console = notice,warning,error,debug messages = notice,warning,error ;full = notice,warning,error,debug,verbose ... Should I change the console... line or uncomment the ;full... line? Either one is fine; using 'full' is actually a bit better, because the color highlighting done on the console sometimes makes console captures hard to read. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com www.asterisk.org ___ -- 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
Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
Set 'canreinvite=no' on all applicable peers? Cyprus VoIP wrote: Hello, We are trying to send faxes by T.38 protocol to a remote SIP proxy from a local extension. The local extension sends the INVITE, Asterisk sends the call to the Proxy the call is connected with a regular audio codec. After a few seconds the remote proxy sends an INVITE with UDPTL and the Asterisk sends it to the local extension and it's accepted, but (here the problem starts) just after sending the OK with the proper SDP to the remote Proxy, the Asterisk initiates a new INVITE to the local extension and remote Proxy, with the normal audio codecs again. We set t38pt_udptl=yes in sip.conf and allowed all the codecs to the local extension and remote Proxy, but it still forces the call to go back to a voice call. Any idea why it happens and how to debug it? We set verbose and debug to 20, but no internal info is provided to get a clear understanding on Asterisk's thoughts during that process. Thank you in advance for your assistance, Andreas ___ -- 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 -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 ___ -- 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
Re: [asterisk-users] Fax Throughput
On Wed, 27 Jun 2007 09:08:21 -0500, Matthew Fredrickson wrote: You fixed your clocking then. That was what I was thinking of. Make sure that your Dialogic card is also pulling timing from the Digium card as well. What version of zaptel drivers are you running? on a related issue, using asterisk 1.2.21 and spandsp 0.0.4 as well as the relevant rxfax and txfax, a loopback fax over an E1 PRI always goes thru at 9600bps. is there a way to increase this, or is it due to the line itself ? -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ --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
Re: [asterisk-users] Fax Throughput
You fixed your clocking then. That was what I was thinking of. Make sure that your Dialogic card is also pulling timing from the Digium card as well. What version of zaptel drivers are you running? --- Matthew Fredrickson Software Engineer Digium, Inc. On Jun 26, 2007, at 2:54 PM, Don Kelly wrote: Matt, thanks for pointing me to zaptel.conf; I'm new to Asterisk and can use all the help I get! Here are the non-comment lines from zaptel.conf (not set up by me): span=1,1,0,esf,b8zs span=2,1,0,esf,b8zs bchan=1-23 dchan=24 bchan=25-47 dchan=48 loadzone = us defaultzone=us The first span is connected to the PSTN. The second is connected to a Windows-based server using Dialogic hardware and custom software. The second span has a clock priority equal to the first one. I'm guessing that this has the effect of ignoring clock from the first span (same as '0') and using clock from the second. Not good. I've changed the clock priority for span 2 to '0'; if we lose the PSTN we'll rely on the Digium card for clock. Fax throughput seems fine with this change. In zapata.conf I find: ; Network Side signalling = pri_cpe group = 1 context = pstn-inbound channel = 1-23 ; IVR Side signalling= pri_net group = 2 context = ivr-inbound channel = 25-47 The default would be switchtype=national, which is correct. I see that for 'signalling', 'group' and 'context' = has been used, rather than the = that I see in documentation. Does this matter? --Don Don Kelly PCF Corp Real Support for your Virtual Office 651 842-1000 888 Don Kell(y) 651 842-1001 fax -Original Message- From: Matthew Fredrickson [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 9:22 AM To: [EMAIL PROTECTED]; Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Fax Throughput Can you post your zaptel.conf so we can verify your timing settings? --- Matthew Fredrickson Software Engineer Digium, Inc. On Jun 25, 2007, at 11:10 PM, Don Kelly wrote: I've tried timing faxes two ways: From a fax machine on a station port of an AltiGen PC/PBX served by an MCI PRI calling back into the same PRI and reaching a RightFax server on a station port behind the AltiGen. From the same fax machine on the same station port of the AltiGen PC/PBX served by the same MCI PRI calling a number on an XO PRI connected to an Asterisk system (Digium TE410P), dialing out on another channel on the same PRI back into the MCI PRI and reaching the RightFax server on the station port behind the AltiGen. extensions.conf includes: exten = 6122353002,1,dial(zap/g1/6122590773) Sending a one-page fax with moderate density (no graphics) takes almost five minutes longer going through the Asterisk server. Any suggestions? ___ --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
Re: [asterisk-users] Fax Throughput
Don Kelly wrote: I've tried timing faxes two ways: From a fax machine on a station port of an AltiGen PC/PBX served by an MCI PRI calling back into the same PRI and reaching a RightFax server on a station port behind the AltiGen. From the same fax machine on the same station port of the AltiGen PC/PBX served by the same MCI PRI calling a number on an XO PRI connected to an Asterisk system (Digium TE410P), dialing out on another channel on the same PRI back into the MCI PRI and reaching the RightFax server on the station port behind the AltiGen. extensions.conf includes: exten = 6122353002,1,dial(zap/g1/6122590773) Sending a one-page fax with moderate density (no graphics) takes almost five minutes longer going through the Asterisk server. The longer transmit time is probably a result either (or both)... 1) retransmissions due to the audio being consistently corrupted, and ECM retransmissions to correct the corruption 2) training failure (probably due to corrupt audio) resulting in a slower transmission rate (e.g. 9600 bps vs 14400 bps) As to how to fix it... it's almost certainly audio degredation occurring in your Asterisk configuration or linkage... so debug your Asterisk setup. Lee. ___ --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
Re: [asterisk-users] Fax Throughput
Can you post your zaptel.conf so we can verify your timing settings? --- Matthew Fredrickson Software Engineer Digium, Inc. On Jun 25, 2007, at 11:10 PM, Don Kelly wrote: I've tried timing faxes two ways: From a fax machine on a station port of an AltiGen PC/PBX served by an MCI PRI calling back into the same PRI and reaching a RightFax server on a station port behind the AltiGen. From the same fax machine on the same station port of the AltiGen PC/PBX served by the same MCI PRI calling a number on an XO PRI connected to an Asterisk system (Digium TE410P), dialing out on another channel on the same PRI back into the MCI PRI and reaching the RightFax server on the station port behind the AltiGen. extensions.conf includes: exten = 6122353002,1,dial(zap/g1/6122590773) Sending a one-page fax with moderate density (no graphics) takes almost five minutes longer going through the Asterisk server. Any suggestions? --Don Don Kelly PCF Corp Real Support for your Virtual Office 651 842-1000 888 Don Kell(y) 651 842-1001 fax ___ --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 ___ --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
Re: [asterisk-users] Fax Throughput
Matt, thanks for pointing me to zaptel.conf; I'm new to Asterisk and can use all the help I get! Here are the non-comment lines from zaptel.conf (not set up by me): span=1,1,0,esf,b8zs span=2,1,0,esf,b8zs bchan=1-23 dchan=24 bchan=25-47 dchan=48 loadzone = us defaultzone=us The first span is connected to the PSTN. The second is connected to a Windows-based server using Dialogic hardware and custom software. The second span has a clock priority equal to the first one. I'm guessing that this has the effect of ignoring clock from the first span (same as '0') and using clock from the second. Not good. I've changed the clock priority for span 2 to '0'; if we lose the PSTN we'll rely on the Digium card for clock. Fax throughput seems fine with this change. In zapata.conf I find: ; Network Side signalling = pri_cpe group = 1 context = pstn-inbound channel = 1-23 ; IVR Side signalling= pri_net group = 2 context = ivr-inbound channel = 25-47 The default would be switchtype=national, which is correct. I see that for 'signalling', 'group' and 'context' = has been used, rather than the = that I see in documentation. Does this matter? --Don Don Kelly PCF Corp Real Support for your Virtual Office 651 842-1000 888 Don Kell(y) 651 842-1001 fax -Original Message- From: Matthew Fredrickson [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 9:22 AM To: [EMAIL PROTECTED]; Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Fax Throughput Can you post your zaptel.conf so we can verify your timing settings? --- Matthew Fredrickson Software Engineer Digium, Inc. On Jun 25, 2007, at 11:10 PM, Don Kelly wrote: I've tried timing faxes two ways: From a fax machine on a station port of an AltiGen PC/PBX served by an MCI PRI calling back into the same PRI and reaching a RightFax server on a station port behind the AltiGen. From the same fax machine on the same station port of the AltiGen PC/PBX served by the same MCI PRI calling a number on an XO PRI connected to an Asterisk system (Digium TE410P), dialing out on another channel on the same PRI back into the MCI PRI and reaching the RightFax server on the station port behind the AltiGen. extensions.conf includes: exten = 6122353002,1,dial(zap/g1/6122590773) Sending a one-page fax with moderate density (no graphics) takes almost five minutes longer going through the Asterisk server. Any suggestions? --Don Don Kelly PCF Corp Real Support for your Virtual Office 651 842-1000 888 Don Kell(y) 651 842-1001 fax ___ --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 ___ --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
[asterisk-users] Fax Throughput
I've tried timing faxes two ways: From a fax machine on a station port of an AltiGen PC/PBX served by an MCI PRI calling back into the same PRI and reaching a RightFax server on a station port behind the AltiGen. From the same fax machine on the same station port of the AltiGen PC/PBX served by the same MCI PRI calling a number on an XO PRI connected to an Asterisk system (Digium TE410P), dialing out on another channel on the same PRI back into the MCI PRI and reaching the RightFax server on the station port behind the AltiGen. extensions.conf includes: exten = 6122353002,1,dial(zap/g1/6122590773) Sending a one-page fax with moderate density (no graphics) takes almost five minutes longer going through the Asterisk server. Any suggestions? --Don Don Kelly PCF Corp Real Support for your Virtual Office 651 842-1000 888 Don Kell(y) 651 842-1001 fax ___ --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
