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. 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 _______________________________________________ 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/
