On Fri, 2008-11-07 at 15:42 -0500, Dale Worley wrote: > I see a lot of value in this. > > On Thu, 2008-11-06 at 20:16 +0000, Scott Lawrence wrote: > > If the caller does not support 2833 and we need to collect DTMF, they > > should get an audio message explaining that the system they are calling > > from is not compatible instead of just sitting there waiting for > > something we're never going to get. > > Diagnosing lack of 2833 should be straightforward -- in order to use > 2833, the telephone-event codec has to be negotiated in the SDP, so the > server has reliable knowledge of whether the caller supports 2833. If > the server attempts to wait for user input, it can test the SDP and > perform a failure response. > > BTW, we should also put a message in the log at ERR or WARNING level, so > we have a record that there was a problematic call. > > > For example - if the callers UA does not claim to support REFER and they > > select a function in an application that is supposed to initiate a > > transfer, the application should play an audio message like: "the > > transfer you selected can not be completed because the system you are > > calling from does not support transfer". At the very least it will be > > easier for the user to make a better bug report. > > The problem with REFER is knowing of the UA supports it. The UA should > list REFER in the Allow header, but some UAs don't do that. In > particular, the LG-Nortel phone and sipXbridge!
If the UA doesn't put REFER in the Allow header (even if we send an OPTIONS to get it in-dialog, which we do in many cases), then we should assume that it does not and act accordingly. If our own UAs don't send proper Allow and Supported headers, those are Critical Bugs and they should be filed and fixed ASAP - this is the foundation of SIP capability negotiation and _lots_ of things won't work right if we don't fix it. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
