I’m using 3 SIP phones, A, B and C. B is registered with Asterisk and acts as transferor. A and C are not registered with Asterisk and act as transferee and target respectively. A calls B, B puts A on hold, then calls C. If C accepts the call, A should be transferred to C and B should hang-up.
I would expect that, after the trasfer, A and C are in direct communication, completely bypassing Asterisk (no active call legs between A and Asterisk and C and Asterisk), so I’m not consuming resources on the Asterisk box. Is that even possible? If so, does anyone know how?
Asterisk is not a SIP proxy, so will not drop out of the SIP path (it is logically two back to back SIP systems). In principle, if you allow re-invites, Asterisk will drop out of the RTP path from A to B, from B to C and from A to C, but I don’t guarantee there are no bugs, and you mustn’t use dial options (e.g. “t” and “T”) which inhibit this.
B and C need to be known to Asterisk to the same degree, i.e. they must be known to the dialplan but needn’t be in sip.conf.
Even if you were to issue a refer directly to C, it is quite likely that A will still insist on setting up the new call via the PABX, as most phones don’t know how to divert to foreign PABXes internally, and firewalls, etc., mean that it probably wouldn’t work if they did attempt to. Similarly, PABXes are likely to ignore the host part and use their own rules to decide who to connect through.
Asterisk’s refer will be to C’s extension number on Asterisk’s host, not to C’s IP address.
To do a SIP supervised transfer, simply do it from a phone with that capability.
I see. Actually I’m using a supervised trasfer capable phone (SJPhone) already. I didn’t mention it before, but the one and only SIP REFER I see is sent by the transferor (B) to Asterisk, when I press the transfer button to transfer A to C. As you clearly stated, the SIP path doesn’t change and no other REFERs are sent.
That brings me onto the next question. I experimented with the transfer command in my dialplan, and it seems it translates, from a SIP standpoint, into a REFER being sent by Asterisk, but the URI is not escaped properly, and there’s no replaces header, so the transfer target rings again because it has no way to understand I’m replacing an existing call.
Is there any way to instruct Asterisk to format the REFER properly?
TRANSFER is, as far as I can tell, only usable for blind transfers. The other problem with it, at least when used after Asterisk has answered the call, is that it returns a success status to the dial plan as soon as it has queued sending the refer, and things get confused if the refer is actually rejected. <http://bugs.digium.com/view.php?id=12713>
However I did get it to work, albeit that the phone used Asterisk to proxy the new call, and another PABX ignored the IP address part. I might not have used a complex enough case for your problem.
I wonder if your problem is that you should be using URIENCODE(), in the dial plan.
If not and you can demonstrate a case where it violates the SIP protocol specification, and you are using an unpatched recent Asterisk 1.4, or 1.6, I think that would justify a bug report on bugs.digium.com. Include the dialplan fragment and relevant protocol traces, preferably using “sip set debug”, and state what you believe should be sent and where that is specified.
You cannot use the bug reporting mechanism to report functionality that you think should be there, but you can, and should use it to report functionality that is there but violates the relevant specification.