Problem with call transfer (flash key and REFER method)

Hi everyone!

I have a problem with call transfer when Asterisk is in the middle of this call. Well, first, I have a proxysip (opensips) that is working great and receives all the SIP messages. The calls between internal SIP phones using the proxysip are OK. The transfers among internal SIP phones are also OK.

When the call is made from the internal PSTN network through Asterisk towards an internal SIP phone (name X), the Asterisk acts as a gateway and makes the call through proxysip to reach the internal SIP phone X. The call works OK, but when SIP phone X tranfers the call by pushing the flash key (REFER message) to an internal SIP phone Y, the Asterisk answers to the REFER message with an Accept followed by a NOTIFY with a “SIP/2.0 481 Call leg/transaction does not exist”.

Does anybody know what can be happening?

The proxy is probably changing the fromtag, totag or call id, but not changing the same in the replaces parameter of the Refer-To: header.

Also note that there is/was a bug in handling certain characters in replaces.

Thanks for your answer. But the proxysip changes only the Contact header from REFER message. The REFER message has the “Refer-To:” with the new fromtag, totag and call id obtained by the new INVITE/OK from SIP phone X to SIP phone Y.

The problem is very similar to this: ser-asterisk-interwork.1460933.n … 89713.html . But I can’t see how to solve it.

Does this bug you mentioned have an issue in asterisk ?

I don’t believe that Asterisk supports refer replaces involving a third user agent, i.e. I don’t think it can generate INVITE/replaces. If you have the situation described in your reference, where the proxy is switching the second leg, I don’t think it is going to work.

The other case, I would have learned about by seeing it on issues.asterisk.org.

Well, is there any way to get around this Asterisk problem ?

I make tests with blindxfer and atxfer and both works OK. The problem is the call transfer using the flash key (REFER message).

The features.conf method will work, even if the proxy would set up the enquiry leg directly, as the features.conf method forces asterisk to set up that leg, so it knows about it.

You need to provide a SIP trace of the two calls.

Hum… well, thanks for your help.
But this problem with call tranfer pointed here is planned to be solved by Asterisk in future versions?