Hello, everyone,
I cannot transfer calls with the transfer command now. The asterisk issues REFER and then BUY. Is this correct? I was told this is the cause of hangup.
It will issue REFER for the Transfer, then BYE when you drop off the end of the dialplan. If the REFER is failing, you need to looks at how the peer responds.
Transfer, on SIP, will use REFER or 302 depending on whether or not the call is already answered.
Everything used to work when the asterisk was connected in the subscriber mode (as a regular phone). The problems began after the asterisk was reconnected in the transit mode as a separate trunk group without registration.
I don’t really understand. Asterisk is a back to back user agent, so it will not relay REFER.
Also, Asterisk itself has no concept of subscriber and trunk mode. These cncepts are not defined by SIP, so you will need to be explicit about what this means in terms of the configuratoin of Asterisk, and its peer.
Those modes are how peer connects asterisk. OK, I will tell the admins of the peer to ask this question to their support.
The support answered that asterisk sends BYE immediately after REFER, but instead it should wait for 202 ACCEPTED. They say some event triggers BUY too quickly. Maybe there is something with timing.
I have red the rfc3515. The problem is that my asterisk after there REFER command issues the BUY command, where as it should follow the following scheme:
Prototypical REFER callflow
Agent A Agent B
| |
| F1 REFER |
|----------------------->|
| F2 202 Accepted |
|<-----------------------|
| F3 NOTIFY |
|<-----------------------|
| F4 200 OK |
|----------------------->|
| |
| |
| |------->
| | (whatever)
| |<------
| |
| F5 NOTIFY |
|<-----------------------|
| F6 200 OK |
|----------------------->|
| |
What parameters should I check to achieve this order of exchange?
Add a Wait in the dialplan.
The BYE is the result of falling off the end of the dialplan, not the Transfer application.
I think their implementation is strange in aborting the new session when the old one is terminated.
I tried to add a wait right after the transfer, but it stops context execution.
Running off the end of the dialplan also stops execution!
I think you need to provide proper logging and copies of the dialplan.
Looking back, you haven’t even told is which SIP channel driver you are using.
I use PJSIP.
The plan is simple:
exten => _.,1,NoOp(Testing transfer)
same => n, Answer()
same => n,Transfer(PJSIP/sip:XXXXXXXXXXXX@XXX.XXX.XXX.XXX:5060) ; REFER
There is no further processing, in the context, for the Wait to delay.
Why are you answering a the call before transferring? If you don’t answer, you will get a 302 redirection which is a much simpler protocol exchange.
I put a wait, but the execution stops at it and exists non-zero.
The goal is to play some greeting message, then a menu and then transfer a call to an external number depending on what button is pressed.
If I do not answer a call, I get a 302 redirection message and then the call ends.
In that case, you did not provide your real dialplan.
I suppose chan_pjsip might be different from chan_sip, but we really need detailed log, including all the tiemstamps (so taken from the full file, not the screen).
I have no real plan, because the transfer application does not work.I am trying to test how it works. If it does, i will build it in real contexts. The support of my provider said that it does not work because the asterisk issues a BUY command right after transfer. I tried to put a wait after it, but it does not work. I made a dump file and opened it in Wireshark, notwithstanding the wait command asterisk sends BYE after REFER.
I need the log from Asterisk, not from whatever you used, as I need to see the relative timing of SIP protocol messages and the dialplan execution to be able to tell whether Asterisk is misbehaving or it is simply a dialplan issue. I need it with Wait () after Transfer ().
However, your trace clearly shows that Asterisk did not initiate a BYE transaction. I was your provider that did that. If it is failing because of the BYE, it is their fault.
There is no such thing as a BUY transaction in SIP!
Your trace also indicates that you re using FreePBX. That would have been important information, as it severely limits the ability to configure round problems.
Sorry, I put an old log.
What I have been told is my REFER message lacks the user part in the contact header. Instead it is in the Refer-To field. How to put the phone number into the user part of the contact header? The number must be the one, I need to transfer call to.
REFER sip:83952248110+h246kluo41060@172.16.254.194:5060;user=phone;transport=udp SIP/2.0
Via: SIP/2.0/UDP 172.16.128.102:5060;rport;branch=z9hG4bKPj46d9ffed-5dd9-436d-be44-f611f32fe1f9
From: “83952450498” sip:83952450498@172.16.128.102;user=phone;tag=45f4bc79-5746-4a3b-a4ff-5c64ed10af9b
To: “83952248110” sip:83952248110@172.16.254.194;user=phone;cpc=ordinary;tag=SD2frd601-8f7ttumxl5
Contact: <sip:172.16.128.102:5060>
Call-ID: SD2frd601-7ac7f5a1ef5dfdc9ecaffd7e8b2ea2dc-c54uv80
CSeq: 4651 REFER
Event: refer
Expires: 600
Supported: 100rel, timer, replaces, norefersub
Accept: message/sipfrag;version=2.0
Allow-Events: presence, dialog, message-summary, refer
Refer-To: sip:83952618718@172.16.254.194:5060
Referred-By: “83952450498” sip:83952450498@172.16.128.102;user=phone
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.3.0)
Content-Length: 0
Wrong. The Contact field in REFER is where NOTIFYs will be sent. The peer should not care about the user part.
Using it as the target of the REFER is completely wrong. If your issue was that they require a user part, or the user part should reflect your own account, there might be some workaround, but that would still involve reading more into Contact than SIP allows.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.