On Wed, Oct 28, 2009 at 5:02 PM, Dale Worley <[email protected]> wrote:
> On Wed, 2009-10-28 at 14:49 -0400, M. Ranganathan wrote: > > So to conclude this saga, the question is - is this an Audiocodes bug. > > If so I can file an XTRN issue. > > I think it is an Audiocodes bug. This is the infamous case of "turning > a consultative transfer into a blind transfer by hanging up on the new > call before it is answered". The problem is that it can't be > implemented directly in SIP; the only solution is for the phone to wait > until the callee answers, and then complete the consultative transfer. > See RFC 5589, section 7.6. > I don't see a good way of handling this in sipXbridge in any event given that I cannot forward the REFER. The best I can do is to wait for the callee to answer but given that Audiocodes already handled the REFER, I am not sure if the Callee even has the opportunity to answer. I have never seen a phone do this (but that does not mean that phones don't do it -- please let me know if I am mistaken). Audio codes must have some special feature to allow you to blind transfer before answering the call. It might be possible to compensate for this bug but given the complications that this hack would create I do not feel we should attempt to compensate for this behavior in 4.0.4. Thanks for your help in looking into this! Regaards, Ranga > In the trace you gave, the Audiocodes sends a REFER to the new leg of > the consultative transfer before the remote UA has answered. But there > is no way for the remote UA to process that REFER sensibly -- it can't > send an INVITE to another UA, because its user is not present at the > originating end of such a dialog. Not that there is any defined error > code for this situation, the REFER RFC is notoriously under-specified. > > Dale > > > -- M. Ranganathan
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
