Hello,
I already wrote a message but maybe the problem I described was pretty unclear, so here a new Try. The thing is it is really urgent and I am not capable to resolve it for myself. Actually I am not a Asterisk Specialist, but I have to use an Asterisk Server for my thesis…
So here the problem in a way breaked down to core-problem:
SIP-Phone1 registered in Asterisk context: [default]
SIP-Phone2 registered in SIPServerX
First
SIP-Phone1 <—Call—> SIP-Phone2
than:
SIP-Phone1 --REFER, with Refer-To:laura@sipY.com–> Asterisk
Now how could I find the “REFER” in the Dialplan!?
That I can do:
[default]
exten-> ???,1,do_something(…)
and the “do_something”, could be anything, or should it be “Dial” or “Transfer”?
If you have canreinvite=yes (or not set) plus a couple of other conditions (such as progressinband=no or unset), transfer will send refer-to. Dial will always use INVITE.
Hello valley,
thank you for your response
But I fear that this not yet resolve my problem:
Asterisk should not send a REFER, it should HANDLE an incoming REFER.
As you could see in the example below SIP-Phone1 sends an REFER to Asterisk, referring to laura@SipY.com
I inserted laura@SipY.com as a peer in sip.conf with context = default
And I wrote in the extensions.conf:
[default]
…
exten => laura,1,Dial(SIP/laura,60)
But when I send the REFER to Asterisk it first answers me with a “REFER accepted”-Message and then sends me NOTIFY, saying:
“SIP/2.0 481 Call leg/transaction does not exist”
I’m not a SIP expert, although that’s a little strange for me. My understanding is, Asterisk should simply relay REFER from SIP-Phone1 to SIP-Phone2 in the scenario you originally decribed, not try to handle a SIP message. SIP protocol specifically says that a SIP proxy should not attempt to act on REFER - I think in your scenario, Asterisk’s function is a proxy.
The only situation in which Asterisk really should handle REFER is when Asterisk answers the SIP call and before it hands the call over to another party.
Asterisk is a back to back user agent. Normally. fpr REFER without replaces, it starts a new dialplan thread in the same was as for an INVITE, but using the original incoming channel.
REFER with replaces is also handled internally by default, but I think you can specify which domains are local, in which case a replace for a call which is not actually local and also not for a local domain will generated an outgoing INVITE/Replaces. There may be some subtle details, and, as very few people use this, it may be buggy.
Note that some SIP phones do INVITE on a second call, followed by REFER/Replaces, even though the user thinks they are doing a blind transfer.
