[Home]

Summary:ASTERISK-18609: When sending fax from Cisco 1751V with t.38, after sending re-INVITE asterisk fully ignore SIP messages from Cisco.
Reporter:Anthony Bloodoff (anthony.bloodoff)Labels:
Date Opened:2011-09-22 10:09:58Date Closed:2012-10-03 15:41:26
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:1.8.7.0 Frequency of
Occurrence
Related
Issues:
Environment:Fedora 14, kernel 2.6.35.11-83.fc14.i686.PAEAttachments:( 0) t38_dump.tgz
( 1) t38_log.txt
Description:When sending fax from Cisco 1751V with t.38, after sending re-INVITE asterisk fully ignore SIP messages from Cisco.
In debug output on asterisk
[Sep 22 19:34:09] WARNING[31769]: res_fax.c:1479 receivefax_t38_init: channel 'SIP/209-00000003' timed-out during the T.38 negotiation.
[Sep 22 19:34:09] WARNING[31769]: res_fax.c:1529 receivefax_t38_init: Audio FAX not allowed on channel 'SIP/209-00000003' and T.38 negotiation failed; aborting.
But in wireshark i see a acceptance (SIP 200 OK) from Cisco.
Comments:By: Anthony Bloodoff (anthony.bloodoff) 2011-09-22 10:11:55.644-0500

Dump collect with tcpdump

By: Anthony Bloodoff (anthony.bloodoff) 2011-09-22 10:12:29.176-0500

log from asterisk (sip debug)

By: Gregory Hinton Nietsky (irroot) 2011-09-22 13:15:32.326-0500

Youve checked the routing and that all the ip's are valid and .... where is the dump taken on the same box as asterisk ???

By: Anthony Bloodoff (anthony.bloodoff) 2011-09-22 23:36:08.321-0500

Dump is collected on  asterisk box (10.66.1.33) and peer is Cisco (10.66.1.38)
Dump is attached as t38_dump.tgz

By: Gregory Hinton Nietsky (irroot) 2011-09-23 03:15:14.623-0500

is this ip your bind addr in sip.conf ?? everything looks good but the packet is not been delivered to asterisk ....

need to figure this out ...

By: Anthony Bloodoff (anthony.bloodoff) 2011-09-23 04:38:02.087-0500

udpbindaddr=0.0.0.0
Listening on all available interfaces
Voice work fine, all troubles appears only after re-invite.

By: Matt Jordan (mjordan) 2012-10-03 15:40:36.099-0500

This looks to be a configuration problem somewhere, but probably not in Asterisk.  The pcap does show that the Cisco device sent a 200 OK to Asterisk's re-INVITE; however, the 200 OK arrives from a different port (5060) than the previous requests/responses received from the Cisco device (55408 for the original INVITE; 57527 for the ACK to the 200 OK).  The fact that your text log file does not show the ACK received from the Cisco device makes me think that either the log has been modified, or something very weird is going on here, since I don't know how Asterisk knew that the 200 OK was received.

Either way, since the responses never show up in the Asterisk log, that would indicate that something is blocking and/or preventing the UDP packet from making it to Asterisk.



By: Matt Jordan (mjordan) 2012-10-03 15:41:26.739-0500

Closing out as not a bug, as this does not appear to be an Asterisk problem.