SIP Refer from Asterisk to Avaya IP Office not working

We have SIP trunks configured between Avaya IP Office and Asterisk. The Asterisk version is Our SIP trunk (at Asterisk end) receives the call from Avaya. Then we play our IVR (a FastAGI application) and afterwards we need to transfer to an agent/softphone on Avaya IP Office, so we use the Transfer function. But this transfer is not working.

I tested it with two Asterisk Servers (connected through SIP trunks), a call initiated on the first Asterisk and received it through the SIP trunk on the second Asterisk, then after playing the IVR, transferred it back to a SIP extension on the first Asterisk server. Basically, the same thing as above but with Avaya replaced as Asterisk. This is working. But with Avaya it doesn’t work.

These are my configuration files (sip.conf, extension.conf)


[avaya] host= ; pbx ip type=peer nat=auto context=access username= ; sip trunk user name secret= ; sip trunk password insecure=invite allow=all


exten => 300,1,Answer()
same => n,Set(CallId=${SIPCALLID})
same => n,AGI(agi://,inbound)

exten => 222,1,Dial(SIP/avaya/115)[/code]

These are the debug logs from both ends (Asterisk and Avaya):

Avaya logs:
Asterisk SIP debug logs:

Please can you tell what is the issue, and on which end is the issue? Also if possible, which configuration is not working.

extensions.conf doesn’t match problem statement: no Transfer call.

Avaya trace doesn’t match Asterisk trace. Former does not have all 7c6dfd96a7cf957d0aea34c2a792f5b6.

Transferring to avaya/ looks wrong. The address in Transfer needs to be the SIP URI that will be used by the Avaya, preumably


We are trying to obtain the logs. In the meanwhile, I’m posting here the logs for SIP transfer (both blind and supervised) between two Avaya IP Offices.

Afterwards, we carried out the same scenario as previous (instead replaced Asterisk with another Avaya IP office) and the testing was successful. Both supervised and unsupervised transfer worked properly via SIP REFER.

The IPs for the two Avaya IP Office are and

We make call from extension 3001@ to 2405@ and then transfer to sip:3003@ in both scenarios (supervised and unsupervised.)

Supervised Transfer:
Unsupervised Transfer:

Can you tell, if possible, what change do we need to make to Asterisk (or at Avaya end) to get it working with Asterisk?

David, here are the logs. I had posted different logs earlier.

Both have same call IDs now. Can you please take a look and tell where is the issue?

Asterisk logs:
Avaya logs:

I guess the Avaya is giving the wrong status code.

Unless the Avaya is strange, you should be referring it to 6000, not avaya/6000.


A little clarification needed, if I just transfer it to “6000”, then wouldn’t Asterisk assume that the 6000 is on Asterisk? The 6000 extension is on Avaya, not Asterisk. It is me who is transferring to “avaya/6000”.

What I do in the FastAGI application is use Exec to do Transfer(SIP/avaya/6000)

SIP/avaya is the SIP user (with it’s host=.)

When I did the same scenario with two Asterisk servers (no Avaya), then I do same Transfer(SIP/asteriskA/6000), and it works properly. Which is why I did the same with Avaya i.e. Transfer(SIP/avaya/6000).

[b]NOTE: Sorry, I have written Dial() in the original post. But we are using the Transfer() application and we use it like Transfer(SIP/avaya/6000)

Sorry for typo.[/b]


The parameters of Transfer are passed unmodified,with the exception that a missing domain name will be filled in with the local domain name. Generally you would want to specify the complete user@domain part of the SIP URI, as expected by the Avaya. sip.conf is completely bypassed.

You should do Transfer(SIP/6000@)

Dear David,

I tried doing Transfer(SIP/6000@, but still it doesn’t works.

SIP logs from Avaya’s side:
The REFER request is at line 850.

Can you please tell what could be the issue now we have also tried changing the format?


Line 882. Plus the Avaya is sending the wrong status code.

Please note that I find use of pastebin sites annoying. It is much better to trim to something that will fit within a code section.

The Avaya is logging a very clear explanation of why it is rejecting the REFER although it is then sending a status code which implies a mismatch on call ID and tags, one which does not actually exist.