<br><br><div class="gmail_quote">On Fri, Mar 20, 2009 at 7:46 PM, Steve Underwood <span dir="ltr"><<a href="mailto:steveu@coppice.org">steveu@coppice.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Gabriel Kuri wrote:<br>
> once the FAX tone is detected on the PSTN side, FS receives a T.38<br>
> re-INVITE from the provider and FS sends back a 488/Not Acceptable<br>
> (proxy_media=false). at that point the provider than attempts fallback<br>
> to PCMU with another reINVITE ...<br>
><br>
<br>
</div>This part is interesting, and the subject of a discussion we had<br>
recently. A number of systems try that second re-invite after a 488, but<br>
the SIP specs say the call is pretty much dead after the 488 message is<br>
exchanged. Are they just hoping that maybe the other end will be<br>
non-compliant enough to keep the call alive, and recover its media mode,<br>
or haven't they read the specs?<br>
<font color="#888888"><br>
Steve</font></blockquote><div><br>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).<br>
<br>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).<br>
<br>draft-ietf-sipping-realtimefax-01 says:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>6.2. Unsuccessful T.38 fax scenario -<br>
- <span style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">488</span>/606 rsp & G.711 fallback <br> <br>
This section represents an unsuccessful SIP T.38 fax call: when the <br> emitting gateway does not support T.38 fax relay, it SHOULD respond <br> with either a ��<span style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">488</span> Not Acceptable Here�� response or a ��606 Not <br>
Acceptable�� response to indicate that some aspects of the session <br> description are not acceptable. The terminating gateway SHOULD <br> react by proposing a fallback to G.711 fax pass-through with special <br>
codec characteristics -<br> -silence suppression OFF. The message details <br> in this section make use of the generic SDP attribute silenceSupp <br> defined in RFC3108 </pre></blockquote>
<div>
<br> rfc3261 section 3 says:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>During the session, either Alice or Bob may decide to change the<br>
characteristics of the media session. This is accomplished by<br> sending a re-INVITE containing a new media description. This re-<br> INVITE references the existing dialog so that the other party knows<br> that it is to modify an existing session instead of establishing a<br>
new session. The other party sends a 200 (OK) to accept the change.<br> The requestor responds to the 200 (OK) with an ACK. If the other<br> party does not accept the change, he sends an error response such as<br>
488 (Not Acceptable Here), which also receives an ACK. However, the<br> failure of the re-INVITE does not cause the existing call to fail -<br> the session continues using the previously negotiated<br> characteristics. Full details on session modification are in Section<br>
14.<br></pre></blockquote>section 14.1 says:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre> If a UA receives a non-2xx final response to a re-INVITE, the session<br>
parameters MUST remain unchanged, as if no re-INVITE had been issued.<br> Note that, as stated in Section 12.2.1.2, if the non-2xx final<br> response is a 481 (Call/Transaction Does Not Exist), or a 408<br> (Request Timeout), or no response at all is received for the re-<br>
INVITE (that is, a timeout is returned by the INVITE client<br> transaction), the UAC will terminate the dialog.<br></pre></blockquote><br> rfc4497 says:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
8.5. Request to Change Media Characteristics<br><br> If after a call has been successfully established the gateway<br> receives a SIP INVITE request to change the media characteristics of<br> the call in a way that would be incompatible with the bearer<br>
capability in use within the PISN, the gateway SHALL send back a SIP<br> 488 (Not Acceptable Here) response and SHALL NOT change the media<br> characteristics of the existing call.</blockquote><div><br> </div></div>
</div></div>