[Freeswitch-users] PCMU fallback for T.38

[Mike Fedyk]

On Fri, Mar 20, 2009 at 7:46 PM, Steve Underwood <steveu at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090701/516b49c4/attachment-0002.html