Summary:	ASTERISK-05239: When T38 re-INVITE is rejected with 488, RTP stream does not resume previous codec.
Reporter:	Ray Van Dolson (rayvd)	Labels:
Date Opened:	2005-10-04 17:03:22	Date Closed:	2011-06-07 14:10:12
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ast.log ( 1) fax.dmp
Description:	Described in this mailing list thread: http://lists.digium.com/pipermail/asterisk-users/2005-October/128058.html Trying to make outbound fax call with G711.  We're going from a Sipura SPA-2002 (public IP, no NAT) to Asterisk and from Asterisk to a SIP/PSTN gateway hosted by a provider (PacWest Telecomm). Fax calls are terminated before negotiation can occur. ****** ADDITIONAL INFORMATION ****** Our ISP appears to be running Audiocodes-Sip-Gateway-TrunkPack 1610/v.4.40.211.387 as their SIP gateway.  I am not sure what they have running as their media gateway. I realize faxing over G711u is hit & miss.  In this situation the negotiation is being terminated because our ISP's SIP/PSTN gateway wants to use T.38.  Here are the sequence of events: Time 0: Asterisk sends INVITE to SIP/PSTN gateway, SDP payload requests G711u. Time 0.07: SIP/PSTN gateway tells us it is Status 100: Try Time 1.59: SIP/PSTN gateway begins transmitting G711u RTP to us. Time 1.65: SIP/PSTN gateway tells us Status: 183 Session Progress with SDP payload of G711u. Time 1.71: Asterisk begins RTP transmission of G711u to SIP/PSTN gateway. Time 12.45: SIP/PSTN gateway tells us Status: 200 OK w/ SDP payload specifying G711U. Time 12.45: Asterisk replies with an ACK, no SDP payload At some point here I believe the first fax negotiation tones are transmitted.  The SIP/PSTN gateway detects this and wants to use T.38. Time 14.05: SIP/PSTN gateway stops transmitting RTP Time 14.15: SIP/PSTN gateway sends INVITE with SDP asking for T.38 Time 14.15: Asterisk replies with Status: 488 Not acceptable here (no SDP payload) Time 14.23: SPI/PSTN gateway replies with ACK (no SDP) (Asterisk is still transmitting RTP to SIP/PSTN -- whether or not they are doing anything with it I do not know) Time 43.1: Asterisk sends BYE request to SIP/PSTN gateway Time 43.27: SIP/PSTN gateway response 200 OK (no SDP) Call ends. Our PSTN provider has told me that Asterisk should send them a re-INVITE to use G711u after we send the 488 reject.  The RFC seems to say that Asterisk can include an SDP payload in the 488 message or the default should be for the other end to fall back to sending the previously negotiated codec -- G711. However, it was suggested to me on the mailing list that Asterisk may be handling this incorrectly. Attached is a tcpdump of one of these fax calls, and I will also attach a debug 4/verbose 4 and sip debug dump of a call as well from the Asterisk console.
Comments:	By: Kevin P. Fleming (kpfleming) 2005-10-04 18:14:18 We will not change the behavior of Asterisk 1.0.x at this point unless there is clearly a bug. As far as sending a new INVITE towards the other end, that is completely wrong. An INVITE (or UPDATE) that is rejected has _zero_ effect; that is why Asterisk continues to send G.711 ulaw RTP towards the peer. They should also do the same, until the T.38 negotiation is successfully completed. I have modified CVS HEAD to not destroy the call when an incoming re-INVITE asks for features we cannot accept; other than that, Asterisk is acting properly according to the RFCs. By: Digium Subversion (svnbot) 2008-01-15 15:50:02.000-0600 Repository: asterisk Revision: 6714 U   trunk/channels/chan_sip.c ------------------------------------------------------------------------ r6714 | kpfleming | 2008-01-15 15:50:02 -0600 (Tue, 15 Jan 2008) | 2 lines don't destroy calls when re-INVITE messages ask for things we can't do (issue ASTERISK-5239) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6714