|
Thanks for the explanation. Right now I’m testing my software module using BroadVoice as my VoIP
provider and two regular land lines to test the call transfer. Based on what you tell me, I’m not sure if the problem is with
BroadVoice or with some of the other two lines (land lines, not VoIP). This
leaves me with two questions: 1) If
the problem is BroadVoice, what other provider I can use that you know offers
unlimited calling and call transfer? 2) Even
using this test environment (BroadVoice + 2 land lines) ExpressTalk is able to
transfer the phone call even when the answer to the REFER command is the 603
message. How do I do this with sipXtapi? Thanks again for your help. -----Original Message----- On Sat, 2006-09-09 at 01:02 -0300, Roman Rusconi wrote: > Maybe my question is obvious but I still don't understand. When
you say > replacing the phone with another model .... What do you mean??? > What do you mean with 'phone'? the VoIP provider? In any consultative transfer (IIRC, you're doing a consultative transfer), there are three SIP "User Agents" (UAs) participating. Colloquially, UAs are called "phones" but of course, they can
be "the other end" of a VoIP provider, or whatever. In order for the consultative transfer to be completed successfully, each of the three UAs needs to execute the correct SIP operations. So if any one of
them does not implement the features that are needed in its role, or refuses to execute a feature at the moment it is needed, the consultative transfer *will* fail. There is no workaround, any more than there
is a workaround if one wheel of a motorcycle is missing. What you are describing is that one of the UAs, when it receives the REFER, responds 603. So the consultative transfer *cannot* work
in this environment. If you wish to continue testing your UA, you should
to replace this UA with one that implements the needed features. Dale _______________________________________________ sipxtapi-dev mailing list List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ |
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
