On Wed, Oct 28, 2009 at 5:23 PM, M. Ranganathan <[email protected]> wrote:
> > > 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. > Actually the inbound call is answered but the second call leg is not answered so that is not a completely accurate statement. > 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 > > -- 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/
