We have noticed an issue with transferring calls outside of the organization. When a call comes in to our asterisk box, and we then transfer it to an outside number, the call gets dropped after about 30 seconds. When simply calling from inside the organization to an outside number, this does not happen. What could be the cause of this?
(the system has been live for quite some time, but I do not know if it’s something that just started happening or was there all along and we are running an ancient 1.2.13).
Thank you for your reply. Can you please elaborate a little bit?
“canreinvite” and “nat” are both set to “no” in sip.conf.
The scenario looks as follows: the call comes in on a zap channel, answered by a sip phone, and is then transferred to an outside number through another zap channel. So, at the time when the call gets dropped neither of the parties are connected to the asterisk box.
This is what the console looks like with verbosity set to 3.
The call comes in and is transferred. However, when the connection disappears, the console doesn’t show anything. So it looks like the connection is still there, it’s just the parties cannot hear each other after 30 seconds or so. Then, when they hang up, the console shows the hang up. Also, when one party hangs up, the other party doesn’t get the signal.
So, about 30 seconds after the transfer completes, everything goes silent. But the call is not dropped since it is still connected on both phones. Even when one party hangs up, the other one is still connected, and will not be disconnected until they hang up.
-- Goto (company,income,16)
-- Executing Queue("Zap/12-1", "secretary|n|||30") in new stack
-- Started music on hold, class 'default', on Zap/12-1
-- Called SIP/secretary2
-- Called SIP/victoria
-- SIP/secretary2-0963b000 is ringing
-- SIP/victoria-09646000 is ringing
-- SIP/secretary2-0963b000 answered Zap/12-1
-- Stopped music on hold on Zap/12-1
-- Started music on hold, class 'default', on Zap/12-1
-- Stopped music on hold on Zap/12-1
-- Started music on hold, class 'default', on Zap/12-1
-- Executing Macro("SIP/secretary2-09653000", "comstar|8905*******") in new stack
-- Executing Set("SIP/secretary2-09653000", "num=8905*******") in new stack
-- Executing Dial("SIP/secretary2-09653000", "ZAP/g1/8905*******") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called g1/8905*******
-- Zap/1-1 is proceeding passing it to SIP/secretary2-09653000
-- Zap/1-1 is making progress passing it to SIP/secretary2-09653000
-- Zap/1-1 is making progress passing it to SIP/secretary2-09653000
-- Zap/1-1 is ringing
-- Zap/1-1 answered SIP/secretary2-09653000
-- Started music on hold, class 'default', on Zap/1-1
-- Stopped music on hold on Zap/1-1
-- Started music on hold, class 'default', on Zap/1-1
-- Stopped music on hold on Zap/12-1
-- Stopped music on hold on Zap/1-1
== Spawn extension (company, income, 16) exited non-zero on 'SIP/secretary2-09653000<ZOMBIE>'
-- Channel 0/1, span 1 got hangup request
-- Channel 0/1, span 1 got hangup
Up to and including the ZOMBIE line, it looks like a successful SIP attended transfer. Unfortunately you screen scraped, rather than using the logs, so I can’t tell where the 30 seconds came in.
As this is such an old version, and my knowledge of Zaptel/DAHDI is limited, I’m not sure I can take this one any further.
However, for the benefit of anyone else, you need to indicate the type of circuit switched hardware in use. I suspect it is primary rate.
The Digium card and, especially if digital, the type of protocol used. There should not be modem on that path. There will either be an analogue pair, or some sort of netweork terminating equipment.
However, the more unusual, the more information is needed.
The Digium card is ‘Wildcard TE210P’. We have a E1 from the telco that comes into a “Watson 5” from schmid device, which is then connected to the digium card. (I am not sure which protocol you are referring to, but this is the info I get from the box: wct4xxp0@pci2:2:0: ).
E1’s can have channel associated signalling or common channel signalling. There are potentially variations in both. For a connection the PSTN, if you have common channel signalling, it is most likely to be ISDN. but DASS and Q.Sig are other possibilities. Not having worked with circuit switched networks on Asterisk, I’m not sure exactly which options are supported, although ISDN and at least one channel associated variant should be.
It is information that would be on the purchase order for the service. It is also information that you would need in order to configure chan_dahdi.conf.