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
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: kpfleming at digium.com Check us out at www.digium.com & www.asterisk.org
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
>> 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 at lists.digium.com/msg234015.html Good luck. JR -- JR Richardson Engineering for the Masses