mfedyk at mikefedyk.com
Guest
|
 Posted: Wed Jul 01, 2009 6:17 pm Post subject: [Freeswitch-users] PCMU fallback for T.38 |
 |
|
On Fri, Mar 20, 2009 at 7:46 PM, Steve Underwood <steveu@coppice.org (steveu@coppice.org)> wrote:
| Quote: | Gabriel Kuri wrote:
| Quote: | 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:
| Quote: | | Quote: | 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:
| Quote: | | Quote: | 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:
| Quote: | | Quote: | 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:
| Quote: | 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. |
|
|
Search
