On Fri, Mar 20, 2009 at 7:46 PM, Steve Underwood <ste...@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.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
