On Fri, Mar 20, 2009 at 7:46 PM, Steve Underwood <steveu@coppice.org> wrote:
Gabriel Kuri wrote:
> once the FAX tone is detected on the PSTN side, FS receives a T.38
> re-INVITE from the provider and FS sends back a 488/Not Acceptable
> (proxy_media=false). at that point the provider than attempts fallback
> to PCMU with another reINVITE ...
>

This part is interesting, and the subject of a discussion we had
recently. A number of systems try that second re-invite after a 488, but
the SIP specs say the call is pretty much dead after the 488 message is
exchanged. Are they just hoping that maybe the other end will be
non-compliant enough to keep the call alive, and recover its media mode,
or haven't they read the specs?

Steve

I am interested in this later document.  From what I can see there is rfc3261 and at least one other RFC (and one draft that I have found after about 30 minutes of searching) that support that a 488 response can be recovered from when it is a response to a reinvite (ie, the dialog is already in place and there is something to fall back to).

Where does it say that a 488 has to end a dialog?  From what I understand there are not any 4xx codes that by themselves terminate a dialog (except where it terminates the last leg of a call -- much like unlink() in unix).

draft-ietf-sipping-realtimefax-01 says:
6.2. Unsuccessful T.38 fax scenario -


                                    - 488/606 rsp & G.711 fallback 
 

   This section represents an unsuccessful SIP T.38 fax call:  when the 
   emitting gateway does not support T.38 fax relay, it SHOULD respond 
   with either a ��488 Not Acceptable Here�� response or a ��606 Not 


   Acceptable�� response to indicate that some aspects of the session 
   description are not acceptable.  The terminating gateway SHOULD 
   react by proposing a fallback to G.711 fax pass-through with special 


   codec characteristics -
                         -silence suppression OFF.  The message details 
   in this section make use of the generic SDP attribute silenceSupp 
   defined in RFC3108

 rfc3261 section 3 says:
During the session, either Alice or Bob may decide to change the


   characteristics of the media session.  This is accomplished by
   sending a re-INVITE containing a new media description.  This re-
   INVITE references the existing dialog so that the other party knows
   that it is to modify an existing session instead of establishing a


   new session.  The other party sends a 200 (OK) to accept the change.
   The requestor responds to the 200 (OK) with an ACK.  If the other
   party does not accept the change, he sends an error response such as


   488 (Not Acceptable Here), which also receives an ACK.  However, the
   failure of the re-INVITE does not cause the existing call to fail -
   the session continues using the previously negotiated
   characteristics.  Full details on session modification are in Section


   14.
section 14.1 says:
   If a UA receives a non-2xx final response to a re-INVITE, the session


   parameters MUST remain unchanged, as if no re-INVITE had been issued.
   Note that, as stated in Section 12.2.1.2, if the non-2xx final
   response is a 481 (Call/Transaction Does Not Exist), or a 408
   (Request Timeout), or no response at all is received for the re-


   INVITE (that is, a timeout is returned by the INVITE client
   transaction), the UAC will terminate the dialog.

 rfc4497 says:
8.5.  Request to Change Media Characteristics

   If after a call has been successfully established the gateway
   receives a SIP INVITE request to change the media characteristics of
   the call in a way that would be incompatible with the bearer
   capability in use within the PISN, the gateway SHALL send back a SIP
   488 (Not Acceptable Here) response and SHALL NOT change the media
   characteristics of the existing call.