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:58 | Date Closed: | 2012-10-03 15:41:26 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | 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.PAE | Attachments: | ( 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. |