REFER / NOTIFY methods according to RFC-3515

I noticed that in chan_sip.c there is a constant SIP_REFER.

Does this mean that Asterisk can initiate SIP-SIP transfers with the REFER / NOTIFY methods according to RFC-3515 ?

If not, why not ? …after all RFC-3515 is almost 3 years old and I thought Asterisk is on the cutting edge of VoIP…

Anyway, if somebody has some code to make Asterisk compliant with this RFC-3515 or some hidden #defines or maybe compiler options to enable this crucial transfer functionality, please scribble something back.

The SIP reinvite method simply does not work with some providers such as Vonage, see my post on the Asterisk Users list/forum. You can try it yourself (I can send you the Vonage host, login and password for testing).
The REFER / NOTIFY methods work every time with all the providers I have ever tried.

Regards,
Daniel

P.S.
Asterisk staying in the media path after the transfer is unacceptable, so please do not suggest setting can reinvite=no.

Related post here => forums.digium.com/viewtopic.php?t=3610

[quote=“Daniel Leeds”]The function sip_transfer (see below) apparently uses the transmit_refer function to transfer SIP calls after they have been answered, using the REFER method according to RFC-3515.
However no REFER requests are evident in SIP debug output when Asterisk transfers such calls. Why?

< sip_transfer: Transfer SIP call (Definition at line 02605 of file chan_sip.c.) >

02605 static int sip_transfer ( struct ast_channel * ast, const char * dest ) [static] 02606 { 02607 struct sip_pvt *p = ast->tech_pvt; 02608 int res; 02609 02610 ast_mutex_lock(&p->lock); 02611 if (ast->_state == AST_STATE_RING) 02612 res = sip_sipredirect(p, dest); 02613 else 02614 res = transmit_refer(p, dest); 02615 ast_mutex_unlock(&p->lock); 02616 return res; 02617 }[/quote]